DEV Community: Ryo Suwito

Blockchain; The damned and cursed hero we need to tame down the chaotic AI mess

Ryo Suwito — Tue, 28 Jul 2026 14:20:16 +0000

Yeah, I know.

Blockchain. NFTs. Web3.

Three words capable of triggering instant PTSD flashbacks involving monkey JPEGs, celebrity rug pulls, Discord servers, and some guy named CryptoAlphaWolf69 telling everyone to “stay strong, community.”

This cannot possibly be serious.

LOL.

Except the more chaotic generative AI becomes, the more this cursed technology starts looking like the exact infrastructure we accidentally built too early.

Because AI is about to create a gigantic problem around one extremely boring question:

Where the hell did this digital thing come from?

And suddenly, boring becomes valuable.

Meet Bob, the unfortunate maestro

Imagine Bob.

Bob is an illustrator. He spends three weeks creating a stitched cartoon character with a unique visual style.

He posts it on Instagram.

A year later, Bob discovers that someone has:

screenshotted the artwork;
removed his signature;
mass-produced it on T-shirts;
listed it on Etsy;
uploaded it to Amazon;
sold stickers on eBay;
fed it into an AI model;
generated 700 suspiciously similar characters;
and somehow made more money from Bob’s work than Bob ever did.

Bob complains to the platforms, provides his Instagram screenshot. The seller replies:

“I made it first.”

Who created the original high-resolution version?

Was the supposedly infringing image copied directly, generated with AI, or merely “inspired” by Bob’s style?

Bob can cry all day, but his evidence trail is basically:

“Trust me, bro. Look at this screenshot.”

That is not a great place to be.

Blockchain is not the judge

This is where people misunderstand the useful version of NFTs.

An NFT is a receipt. It is evidence, a digital footprint that does not depend entirely on Instagram, Amazon, Bob’s laptop, or some startup continuing to pay its AWS bill until the heat death of the universe.

Think of CCTV.

A CCTV company does not care whether the footage records a robbery, a divorce dispute, a workplace accident, or your neighbour stealing your Amazon package.

The footage simply creates an evidentiary object that investigators, platforms, insurers, lawyers, and courts can evaluate later.

Then AI kicks the door off its hinges

Copying digital work was already easy. Then Generative AI makes it industrial.

A user can upload Bob’s artwork into an image generator and request:

“Make this character slightly different, wearing sunglasses, riding a dragon, in the style of a premium children’s animation studio.”

Five seconds later, Bob is no longer fighting one stolen image.

He is fighting an infinite mutation factory.

The infringement may no longer be pixel-for-pixel identical. It could be transformed, cropped, recoloured, restyled, combined with other works, or reconstructed from visual features.

Welcome to the synthetic-media circus.

The two-way evidence machine

Now imagine a Midjourney-like platform that takes provenance seriously.

One insomniac engineer drinks three cans of Jack Daniel’s and Coke, walks into a meeting, and yells:

“WHAT IF WE PUT THE DAMN RECEIPTS ON-CHAIN?”

The CTO laughs.
The VC pauses.
Someone makes a slide deck.

Six months later, the company announces Trusted Creative Provenance™, carefully avoiding the letters N, F, and T.

The system could work in both directions.

Before generation

A user uploads an image as a reference.

The platform creates:

an exact cryptographic hash;
a perceptual fingerprint;
an embedding for visual similarity;
a record of declared ownership or licensing;
a comparison against registered works.

If the uploaded image strongly resembles Bob’s registered artwork, the platform can:

warn the user;
limit commercial generation;
request proof of licensing;
offer a licensing pathway;
attach the source relationship to the generated result;
or block the request entirely.

The blockchain is not performing the AI image search. That would be absurdly inefficient. The AI system performs the search.

The chain preserves the claims, timestamps, licences, identities, and resulting evidence.

During generation

Every generated image can receive a signed provenance record containing:

the output file hash;
the generation timestamp;
the model and version used;
hashes of reference images;
the account or verified identity that requested it;
the platform’s cryptographic signature;
the declared licensing terms;
the editing history;
and links to previous versions.

The user does not need to understand wallets. They do not need to chant “Web3.”

They do not need to hold a cartoon ape.

They click Generate, and the platform quietly creates the receipt.

The interface might simply say:

Verified generation history available

Very corporate and boring but potentially very valuable.

After abuse occurs

Now imagine someone generates a fabricated image of a politician, celebrity, CEO, journalist, or random private citizen doing something they never did.

Investigators run AI-powered visual search across public databases, platforms, and provenance registries.

The system finds:

visually related images;
earlier versions;
source assets;
generation records;
editing steps;
wallet attestations;
platform signatures;
and the first known timestamp.

If the creator used a KYC-verified account, the public does not necessarily need to see the creator’s passport or home address.

Instead, the public record can say:

“This account’s identity was verified by Provider X.”

Then, through proper legal or platform procedures, the responsible identity can be disclosed when necessary.

“Why not just use DynamoDB?”

Because, yes, technically, you can.

You can store every claim in DynamoDB or PostgreSQL.

You can put it in an Excel file if you are sufficiently unhinged.

The technical problem is not whether a database can store:

Bob registered image hash ABC123 at 14:32.

Of course it can. The real problem is:

Who keeps paying to preserve that record for the next 30, 50, or 100 years?

Who guarantees that the company will not:

shut down;
get acquired;
delete unprofitable records;
alter disputed entries;
lose the backups;
change its terms;
block access in certain countries;
or decide that storing 400 billion abandoned provenance records is not commercially attractive?

AWS has enormous infrastructure, but it does not have a moral obligation to preserve Bob’s cartoon receipt forever.

Neither does Instagram. Neither does Etsy. Neither does the AI startup that generated the derivative image.

A centralised registry can work brilliantly while the company operating it remains trustworthy, solvent, and interested.

The blockchain proposition is different.

It says:

“Let us create an economic system where thousands of strangers preserve shared state for selfish reasons.”

That sounds terrible LOL, but it also happens to be useful.

Let's be honest, validators want fees. Token holders want network value. Storage providers want payment.
Everyone want a piece of cake.
Nobody needs to care personally about Bob.

Their greed keeps the machinery alive.

That may be blockchain’s most underappreciated feature:

The record survives not because everyone is good, but because enough people are economically motivated to preserve the system.

Crooked incentives can produce surprisingly durable infrastructure.

Nobody will call it an NFT

This may be the funniest part.

The technology might win only after everyone stops using the name.

Shutterstock will not announce:

“Shutterstock NFT ApeChain Creator Moon Vault.”

Please, God, no.

It will announce something like:

Shutterstock Provenance: register, license, verify, and track creative assets.

Adobe might call it:

Authenticity Credentials

A film studio might call it:

Digital Asset Chain of Custody

A marketplace might call it:

Verified Original Listing

An AI company might call it:

Generation Trace

An insurer might call it:

Creative Rights Evidence Infrastructure

Underneath the respectable corporate vocabulary:

cryptographic tokens;
distributed ledgers;
content-addressed storage;
smart contracts;
wallet attestations;
and automated licensing.

Same damned machinery. New suit. Less monkey.

The monkey JPEG PTSD may be the opportunity

That trauma is understandable and may prevent people from noticing when the underlying infrastructure gets repurposed.

The crowd is staring at the corpse of NFT speculation. Meanwhile, AI is quietly creating the strongest practical argument for digital provenance that the internet has ever seen.

The opportunity, if there is one, may come from the delay.

Startups need time to realise what product to build. Creators need time to trust it. Platforms need time to integrate it. Studios need time to establish workflows. Courts need time to interpret it.

Regulators need approximately 700 years and several committee hearings to decide what the words mean.

During that lag, everyone remains convinced the entire field is dead.

Maybe it is.

Or maybe the label is dead while the infrastructure waits for its actual job.

The damned and cursed hero

Blockchain does not need to save democracy. It does not need to replace every bank. It does not need to decentralise your toaster.

It only needs to become useful in places where:

records must survive;
parties do not fully trust each other;
no single company should own the entire history;
timestamps matter;
tampering matters;
and preserving shared evidence creates long-term value.

The coming AI mess checks a suspicious number of those boxes.

So yes, the idea sounds ridiculous:

Use the technology famous for monkey JPEG speculation to help control AI plagiarism, trace deepfakes, register digital rights, document creative history, and provide evidence across platforms.

LOL.

Absolutely cursed. Possibly inevitable.

And somewhere, right now, an insomniac developer is opening a pitch deck and typing:

“Blockchain-powered intellectual-property provenance for the synthetic-media economy.”

The VC will stare at it. The CTO will swear. The product manager will remove the word “blockchain.”

They will call it TrustLayer AI™.

And everyone will pretend this was never an NFT idea.

That is when the damned thing might finally make money.

The Endgame of AI Open Weights Is Not for Us GPU Plebs

Ryo Suwito — Tue, 21 Jul 2026 07:40:50 +0000

Daaamn, bro.

For the last few years, whenever an AI lab released an open-weight model, the developer community reacted like someone had just air-dropped freedom into our basements.

“Can my RTX run this thing?”

For a while, that was the dream.

A frontier-ish model running locally. No API bill. No corporate gatekeeper. No mysterious model update ruining your workflow overnight. Just you, your GPU and our beloved llama.cpp.

But I am starting to think we misunderstood the endgame.

The future of open weights may not be about helping individual developers run increasingly powerful models at home. Maybe it's all about helping someone else build the infrastructure required to run them at industrial scale.

Two Frontiers, Two Strategies

At the moment, the Western and Eastern AI frontiers appear to be moving in very different directions.The Western frontier is increasingly obsessed with keeping the beast inside the walled garden.

The strongest models live behind APIs, subscriptions, product tiers, safety evaluations, regional restrictions, usage policies, and whatever new compliance ritual appeared this week.

Meanwhile, several Eastern AI labs appear to be asking something closer to:

“What happens if we release the beast and let the ecosystem figure out how to feed it?”

That difference matters.

The “Dangerous Model” Saga Is Getting Weird

Whenever a powerful open-weight model appears, the same argument returns.

It is too dangerous.
It can write malware.
bla bla bla...boring

Sure. Those risks are real.

But when you look deeper, some of the public discourse starts sounding less like safety analysis and more like strategic fearmongering.

Because the convenient conclusion is almost always the same:

The model is dangerous, therefore the model must remain under the control of the company that built it.

Well, damn. How fortunate for the company.

Then Why Release a Gigantic Model for Free?

This is the part that kept bothering me.

Training frontier models costs a ridiculous amount of money. Then, after spending all that money, you release the weights?

Why?

My shower thought is this:

Models may become free, but compute never will.

That changes the business model completely.

The Goal May Be to Become the AWS of AI

Suppose a lab releases an extremely capable open-weight model. Immediately, developers start experimenting with it, Researchers benchmark it.

Then the money keeps pouring in:

Cloud providers race to support it.
Hosting platforms advertise it.
Enterprise vendors build private deployments around it.
Consulting firms start selling integration packages.

Suddenly, the entire ecosystem is spending money to create infrastructure for the lab’s model.

That open-weight release creates:

demand for inference,
demand for optimized kernels,
demand for GPU clusters,
demand for managed endpoints,
demand for fine-tuning,
demand for monitoring,
demand for enterprise support,
and demand for specialized deployments.

Once enough infrastructure is organized around your model family, you gain leverage. That is a very different game. And frankly, it may be more sustainable than trying to own every layer yourself.

Open Weights as Infrastructure Subsidy

Western frontier labs often try to do nearly everything internally.

Train and Host the model.
Build the API and the consumer app.
Build the enterprise product and the agent platform.
You name it..

But holy crap, that is a lot of surface area. The open-weight strategy distributes some of that burden. Instead of paying to build every possible deployment configuration, a lab can release the weights and let the market explore them.

Cloud companies figure out serving.
Startups build specialized interfaces.
Developers create integrations.

That may be the real genius of the strategy. Open weights can function as a subsidy for future compute demand.

The Model Is Free. The Cluster Is Not.

This is where the dream of local AI starts colliding with physics.

A model can be legally downloadable and still be practically inaccessible.

The architecture may use sparse activation and clever efficiency tricks, but the total system may still require enormous memory, high-bandwidth interconnects, specialized kernels, distributed inference, and a painful amount of engineering.

Sure, someone will quantize it.

Someone always quantizes it.

There will be an IQ1_S_DAMN_NEAR_BINARY version uploaded by a wizard with an anime avatar.

And technically, perhaps, it will run. At 0.4 tokens per second. With half the layers on CPU. While your RAM begs for death.

Congratulations, bro. You are sovereign now.

Free as in weights.
Expensive as hell as in reality.

The Eastern Labs Are Not Stupid

It would be naive to assume that labs releasing open weights simply forgot how capitalism works. The open release may be the customer-acquisition strategy.

Not only for individual developers, but for the infrastructure providers who will eventually serve those developers.

Today:

“Here are the weights.”

Tomorrow:

“Here is the officially supported deployment stack.”

Later:

“Here is our premium model license, enterprise runtime, certified hosting network, and revenue-sharing agreement.”

Final Thought

Open weights are still valuable.

They improve transparency, enable research, create competitive pressure against closed platforms. Whatever...

The weights may be free.
The future invoices will not be.

So no, the endgame of AI open weights may no longer fit inside your RTX bullcrap.

And it may definitely not fit in your mom’s basement with ComfyUI running in the background.

Welcome to the cloud, GPU plebs.

The Cope, the Lie, and the No-Hope Post-AI Era

Ryo Suwito — Fri, 10 Jul 2026 16:32:24 +0000

TL;DR

No, AI did not take your job.

It just doubled your workload while quietly kicking Bob off the employment wheel.

Preamble: What the Fuck Are We Even Doing Here?

AI is not some yesteryear tech.

It is not immature.

If you think AI means whatever OpenAI and Anthropic have been churning out since 2023, I am sorry, dude, but this thing started way back when we were still sperm.

Literally decades ago.

The hype came and went. Promises got inflated. Products underdelivered.

Classic tech cycle.

Claude Shannon and countless other researchers poured their days, nights, careers, and probably sanity into trying to make a damn rock think.

And now you discredit all of that by calling it a slop machine.

Clap.

Today’s AI is arguably as mature as the internet itself, at least if you compare their trajectories fairly.

The progression is beyond insane. Your brain just cannot comprehend the scale of it, so it compresses everything into: “Eh, autocomplete with extra steps.”

That is like saying the Big Bang theory was just some guy daydreaming too hard.

But for the first time in all those decades, something has materially changed.

In 2026, Bob really is being replaced by an unknown entity roaming around a datacenter somewhere.

Not because the entity does Bob’s exact job perfectly.

It does not need to.

It only needs to do enough of Bob’s work, reliably enough, that Alice can now handle what used to require Alice, Bob, and half of Charlie.

The company does not need zero Bobs.

It just needs fewer Bobs.

Cope as hard as you want.

The burn has already happened.

The Lie: Damn, Snake-Oil Sellers Love This One

They told you companies would replace Bob with a digital Bob.

Nah.

That was never the real play.

The quality is okay. Sometimes impressive. Sometimes garbage. Current mid-to-top-tier models can maybe exceed baseline human ability in certain tasks, especially because they do not get tired, wake up pissed off, take sick leave, or spend half the afternoon doomscrolling.

But here is the part AI labs rarely say out loud:

You are probably too broke to afford the version that actually replaces Bob.

Dude, seriously.

The trap is in the pricing.

Technically, the labs trapped themselves too.

It goes something like this:

First, they seduce everyone with subsidized pricing.

Then some CTO storms into a meeting, bangs the desk, and tells the CFO:

“See? Digital Bob only costs us $200 a month. Let’s cut half of those sleazy developers.”

Easy, right?

Not exactly.

In some parts of the world, maybe the math works.

But the catch is globalization.

These companies want to capture the biggest possible total addressable market. That means serving every kind of company, in every country, at wildly different levels of purchasing power.

That disparity becomes brutal when they eventually pump the brakes on flat-rate subsidies.

Let’s do some napkin math.

A current $200 subscription, when abused by a genuinely heavy professional user, might consume more than $1,000 worth of tokens if the same usage were billed directly through an API.

For a well-funded company in the American Midwest, $1,000 a month might still sound cheap.

Globally?

LOL.

In plenty of countries, a junior or mid-level employee sits in roughly the same pricing bucket.

So why spend all day yelling at a machine when you can yell at the real Bob after he deletes the production database on a Friday afternoon?

You pay roughly the same amount, Bob understands office politics, and you can sue him.

Good luck suing an AI lab after its model confidently wipes out your business.

There Is No Hope. Seriously.

If your biggest cope is hoping AI will fade away like NFTs, crypto hype, or RepRap-style desktop manufacturing dreams, then, bro, you have not been following technology for very long.

Those things are niche.

A lot of them are solutions wandering around looking for a problem.

AI is harder to kill because it already solves real problems.

Take the dumbest, smallest use case possible.

This dev.to article needs a stock image.

Your mom’s secret-recipe YouTube video needs a thumbnail.

You search Google Images. You scroll Pinterest. Everything looks almost right, but not quite.

Then, bam.

You open an image generator, type the chaos inside your brain, wait a few seconds, and you are done.

You slap the result onto your content.

Problem.

Solved.

That alone is enough to make this stuff sticky.

AI is going to cling to society like your shirt after a Sunday jogging session.

It is not fading away.

And no, that does not mean all the Bobs eventually get their jobs back.

Nah.

Nada.

This is harsh. It is heartbreaking.

But I am not here to lead a support-group session.

Remember the women working telephone switchboards in the early days of telecom?

At one point, they were among the busiest workers in the system, manually connecting landline calls from one John to another John.

Then they were replaced by a damn box.

Switches. Multiplexers. Automated exchanges.

Their jobs did not become easier.

Their profession became obsolete.

So here is the only question that matters:

Do you want to become one of them in 2026?

Logic-Graph Verification System

Ryo Suwito — Thu, 02 Jul 2026 07:27:02 +0000

Status: Draft v1 · 2026-07-02
Author: design session (Claude Fable 5)
Implementer: any capable coding model, per SYSTEM-DESIGN.md

1. One-liner

Convert the cheap token throughput of open-weight thinking models into verified conclusions, by externalizing their reasoning as a graph, sampling it N independent times, and letting mechanical graph checks — not model vibes — decide what survives.

2. Problem

Self-correction by prompting fails. Re-feeding a model its own chain-of-thought ("let's revisit...") makes it anchor to its own tokens and rubber-stamp itself. Known result (Huang et al., "LLMs Cannot Self-Correct Reasoning Yet").
tokens/sec is a garbage metric. A cheap model emitting 1M tokens of confident nonsense is worth less than nothing. The metric that matters is correct conclusions per dollar.
Verification-by-LLM inherits the problem. Asking a model "is this true?" just moves the vibes one level up. We need checks that are mechanical — computable, deterministic, not model-judged.
Cheap models confabulate from pretraining. A system whose claims must trace to imported sources cannot tolerate a model that silently answers from its weights.

3. Core insights (the product thesis)

Shape is checkable even when truth isn't. An argument externalized as a directed graph admits mechanical checks: unsupported premises (orphans), circular reasoning (cycles), disconnected conclusions (reachability), refuted-claims-still-load-bearing.

"Truthiness" becomes topology. Confidence in a conclusion ∝ how many node-disjoint chains connect evidence to it (Menger's theorem). One road to Rome = fragile; three independent roads = an adversary must break three separate claims.

Independence is sampled, not requested. Asking one context for "3 independent arguments" yields the same argument paraphrased 3 times. Asking N independent inference calls (fresh context, temperature > 0) yields genuinely decorrelated attempts — the detective's technique: separate interrogations, then cross-examine. Contradictions between runs are the interrogation slip-ups; they are invisible inside any single transcript.

Direct attention, don't diffuse it. "Revisit your reasoning" makes a model skim everything shallowly. "Edge 7 is load-bearing and unverified" makes it spend its whole budget on the right spot. Min-cut/betweenness computes where that spot is.

The formalization tax is a feature. A vague step becomes visibly vague when it must be written as a typed node with typed edges.

4. Users & use cases

Primary user: a developer/researcher running multi-step reasoning or research-over-documents workloads on cheap open-weight models (via OpenRouter or local inference), who needs reliability without frontier-model prices.
Use cases:
- U1: Multi-hop question answering over provided documents, with an auditable argument graph as output.
- U2: Claim verification — "here is a conclusion; how much would have to be wrong for it to fail?"
- U3: As an MCP tool available to any agent, giving it external working memory for arguments plus structural self-checks.

5. Goals & success metrics

#	Goal	Metric	Target
G1	Screening identifies grounded models	screen produces grounded% / memorized% / abstain% per model	screen runs end-to-end < $1
G2	System beats naive self-correction	accuracy on eval set vs "revisit" and verbatim re-injection arms	≥ +5pp at equal or lower cost
G3	Cheap ensemble beats one big call	correct-per-dollar vs one frontier-class call	≥ 2× correct-per-dollar
G4	Confidence is calibrated by structure	conclusions with support width ≥ 2 are correct more often than width 1	monotone relationship observed
G5	Auditable output	every conclusion ships with its graph: surviving claims, width, disputed nodes	100% of runs

6. Non-goals

Not a truth oracle. The graph verifies argument shape; every edge is semantically vouched for only by a model. Validly-connected garbage passes structure checks — by design, the structural layer only decides where semantic effort (re-interrogation) goes.
No fine-tuning, no inference-loop surgery. Everything works through standard chat-completions + tool calls. No custom sampling, no template hacking, no stop-at-</think> interception.
No persistence. Graphs are session-scoped and ephemeral (in-memory). No database.
Not a general theorem prover. Natural-language claims, heuristic dedup — not formal logic.

System Design

1. Architecture

Two deployment modes for the graph server, same codebase:

Library mode (default for orchestrator): orchestrator imports graph_server.store directly, no MCP transport. Simpler, faster, use for P3/P4.
MCP mode: server.py exposes the same functions as MCP tools over stdio, so any MCP-capable agent (Claude Code, etc.) can use the graph as external working memory. Thin wrapper only — zero logic in the transport layer.

2. Component A — Grounding screen (P1, exists)

Already implemented at repo root: screen.py, items.jsonl (50 items), models.json. Contract: temperature 0, 1 call/item/model, regex-graded. See README.md. Output feeds one decision: which model id the orchestrator defaults to. Do not modify except to fix bugs.

3. Component B — Graph server (P2)

3.1 Data model

In-memory only. One GraphStore holds many independent graphs keyed by graph_id (string, caller-supplied).

Node:
  id: str            # caller-supplied, unique within graph, e.g. "r2:n4" (run 2, node 4)
  claim: str         # natural-language claim, one sentence
  type: str          # "given" | "inference" | "assumption" | "conclusion"
  confidence: float  # 0.0-1.0, model-stated, default 0.8
  run_ids: set[str]  # provenance: which interrogation runs asserted this claim
  refuted: bool      # default False, set only via mark_refuted
  refute_reason: str | None
  aliases: list[str] # claims of nodes merged into this one (dedup provenance)

Edge:
  src: str, dst: str
  relation: str      # "supports" | "attacks" | "assumes"
  confidence: float  # 0.0-1.0, default 0.8
  run_ids: set[str]

Backed by one networkx.MultiDiGraph per graph_id (multi because supports and attacks may both exist between the same pair). Node attrs hold the Node fields; edge attrs hold relation/confidence/run_ids.

Validation on ingest (reject with error message, don't crash): unknown type/relation, edge endpoints not in graph after this ingest, confidence outside [0,1], duplicate node id with different claim text (same id + same claim = idempotent, merge run_ids).

3.2 Public functions / MCP tools

Eight functions. Signatures below are the library API; MCP tool schemas mirror them 1:1 with graph_id always the first param.

#	Function	Params	Returns
1	`assert_graph`	graph_id, nodes[], edges[]	`{accepted_nodes, accepted_edges, rejected: [{item, reason}], auto_merged: [[kept_id, merged_id], ...]}` — runs dedup (§3.3) on the new nodes against existing ones automatically
2	`merge_duplicates`	graph_id, jaccard_threshold=0.7, ratio_threshold=0.85	`{merges: [[kept_id, merged_id]], contradictions_created: [[id_a, id_b]]}` — full-graph re-pass
3	`check_structure`	graph_id, conclusion_id	`{orphans: [id], cycles: [[id,...]], unreachable_conclusion: bool, refuted_but_feeding: [id]}`
4	`critical_links`	graph_id, conclusion_id	`{min_cut_nodes: [id], bridge_edges: [[src,dst]], ranked: [{edge, betweenness, min_confidence_on_edge}]}` sorted least-confident-first
5	`support_width`	graph_id, conclusion_id	`{disjoint_paths: int, paths: [[id,...]], max_flow: float}`
6	`surviving_claims`	graph_id	`{in: [id], out: [id], undecided: [id], surviving: [id]}` (§3.5)
7	`mark_refuted`	graph_id, node_id, reason	`{ok, width_before, width_after}` for the graph's conclusion node if one exists
8	`disputed_nodes`	graph_id, conclusion_id	`{contradiction_pairs: [[id_a, id_b]], isolated_load_bearing: [{id, run_count, on_path}]}` (§3.6)

Every function MUST be pure-read except 1, 2, 7. Every function MUST return JSON-serializable dicts. Errors return {error: "..."}, never raise across the MCP boundary.

3.3 Dedup / merge (THE load-bearing component)

Purpose: identical claims from different runs MUST collapse to one node, otherwise (a) support width is inflated by paraphrase and (b) contradictions never meet each other.

Normalization norm(claim):

lowercase; unicode NFC
strip punctuation except . inside numbers and %
canonicalize numbers: remove thousands separators (84,200 → 84200)
collapse whitespace
tokenize on whitespace; drop English stopwords (small fixed list: a, an, the, is, are, was, were, of, in, on, at, to, that, this, it, and)

Negation guard (checked BEFORE similarity): let NEG = {not, no, never, cannot, "n't", without, false}. If tokens(a) - NEG == tokens(b) - NEG but the two differ in negation-token count parity → DO NOT merge; instead create mutual attacks edges between them and report in contradictions_created.

Numeric-conflict guard: if token sets are equal except for differing numeric tokens (e.g. "trellium melts at 412" vs "trellium melts at 350") → do not merge; create mutual attacks edges and report.

Similarity (only if guards pass): merge iff jaccard(tokens_a, tokens_b) >= 0.7 OR difflib.SequenceMatcher(None, norm_a, norm_b).ratio() >= 0.85. Both thresholds tunable via config. (v1 upgrade path, out of scope: cosine over a small sentence-embedding model; keep the interface identical.)

Merge policy: keep the node with the earliest assertion (stable order: first run_id, then node id). Union run_ids and aliases; keep max confidence; re-point all edges to the kept node; collapse resulting parallel edges of the same relation (max confidence, union run_ids). given type wins over inference wins over assumption if merged nodes disagree on type. Never merge a refuted=True node into a live one — merge live into refuted keeps refuted.

Clustering: union-find over pairwise matches (O(n²) pairwise is fine; graphs are hundreds of nodes, not millions).

3.4 Structural checks (networkx recipes)

Work on the supports+assumes subgraph (attacks edges excluded) unless stated. Build D = nx.DiGraph view collapsing the multigraph, keeping max confidence per (src,dst).

orphans: nodes with in-degree 0 that are not type=given and not type=assumption (assumptions are declared floats; still reported separately as assumptions in the payload — implementer: include key assumptions: [id]).
cycles: list(nx.simple_cycles(D)), cap output at first 10.
unreachable_conclusion: conclusion not in descendants(D, g) for any given g. Compute once: reachable = union of nx.descendants(D, g) | {g} for all givens; unreachable iff conclusion not in reachable.
refuted_but_feeding: nodes with refuted=True that still have a path to the conclusion in D.
critical_links: nx.minimum_node_cut(D_aug, s, t) and betweenness via nx.betweenness_centrality_subset(D, sources=givens, targets=[conclusion]). For s-t computations with multiple sources add a virtual super-source __S__ with edges to every given (confidence 1.0), and use conclusion as sink; NEVER report __S__ in results. Bridge edges: edges whose removal makes conclusion unreachable (test each edge on the paths; graphs are small, brute force is fine).

3.5 support_width & surviving_claims

support_width (Menger): on D_aug (super-source __S__ → all non-refuted givens):

disjoint_paths = len(list(nx.node_disjoint_paths(D_aug, "__S__", conclusion))) — strip __S__ from reported paths. Handle NetworkXNoPath → 0.
max_flow: capacities = edge confidence; node capacities = node confidence (implement via standard node-splitting: v → v_in, v_out with capacity = confidence). nx.maximum_flow_value on the split graph. Givens and __S__ edges get capacity ∞ (use 1e9).

surviving_claims (grounded semantics over attacks, then reachability):

A = subgraph with attacks edges only (all nodes, attack edges)
label all nodes UNDEC
repeat until no change:
    node -> IN  if every attacker of it is OUT (vacuously true if no attackers)
    node -> OUT if some attacker of it is IN
# refuted nodes are forced OUT before the loop starts
surviving = { n : label(n) != OUT
              and (type(n)=="given"
                   or n reachable from some IN/UNDEC given
                      via supports/assumes edges through only non-OUT nodes) }

Return the full labelling plus surviving.

3.6 disputed_nodes

contradiction_pairs: all pairs connected by mutual attacks created by the guards in §3.3, plus any pair the caller asserted with explicit mutual attacks.
isolated_load_bearing: nodes with len(run_ids) == 1 AND (betweenness_subset > 0 from givens to conclusion OR node lies on any given→conclusion simple path). These are the prime confabulation suspects; the orchestrator re-interrogates them first.

4. Component C — Orchestrator (P3)

CLI: python -m orchestrator.run --task task.json --model <id> --n 6 --k 2 --budget-calls 20 --temp 0.8

task.json: {"question": str, "documents": [str], "expected_answer": str|null} (expected_answer only used by the eval harness).

4.1 Control loop

1. FAN OUT: N parallel interrogation calls (fresh context each, temperature=temp).
   Each call gets: system prompt (§4.2) + documents + question.
   Parse each response's JSON graph (§4.3). assert_graph with run_id="r{i}",
   node ids prefixed "r{i}:".
2. MERGE: merge_duplicates(graph_id).
3. ASSESS: check_structure, support_width(conclusion), disputed_nodes.
   The conclusion node: each run marks exactly one node type=conclusion; after
   merge there should be 1..N conclusion nodes. If >1 cluster of conclusions
   survive dedup, the runs DISAGREE on the answer itself -> treat each cluster
   as a candidate; the report ranks candidates by support width.
4. RE-INTERROGATE (while budget remains and disputed set nonempty):
   For each disputed node (contradiction pairs first, then isolated load-bearing,
   max 3 per round): send M=3 fresh verification calls (§4.2 template B: the
   claim + documents ONLY — no graph, no prior transcript). Majority verdict:
   - refuted by >=2 of 3 -> mark_refuted(node, reason)
   - confirmed by >=2 of 3 -> bump confidence to max(old, 0.9), add run_id "v*"
5. STOP when: (a) no disputed nodes remain, or (b) all conclusion candidates
   stable AND top candidate width >= k, or (c) budget-calls exhausted.
6. REPORT: JSON + rendered markdown: chosen conclusion (claim text), support
   width + disjoint paths, surviving_claims, killed nodes with reasons,
   remaining disputed, per-call and total cost, wall clock.

4.2 Prompt templates (verbatim starting points; iterate only with eval evidence)

Template A — interrogation (system):

You are building a rigorous argument. Read the documents, then answer the
question by constructing an explicit reasoning graph.

Rules:
- Every claim must come from the documents or be an explicitly labeled
  assumption. Do not use outside knowledge.
- Aim for at least {k} independent lines of support for your conclusion,
  but NEVER invent support: a single honest chain beats two fabricated ones.
- If you find evidence against a claim, include it as a node with an
  "attacks" edge. Objections make the graph stronger, not weaker.

Output ONLY a JSON object, no prose, matching:
{"conclusion_node": "<node id>",
 "nodes": [{"id": "n1", "claim": "<one sentence>",
            "type": "given|inference|assumption|conclusion",
            "confidence": 0.0-1.0}],
 "edges": [{"from": "n1", "to": "n2",
            "relation": "supports|attacks|assumes",
            "confidence": 0.0-1.0}]}
"given" = stated in a document. "inference" = derived. Every inference must
have at least one incoming supports edge.

Template B — verification (system; fresh context, no graph shown):

Assess one claim against the documents. Reply ONLY with JSON:
{"verdict": "supported" | "refuted" | "not_determinable",
 "reason": "<one sentence citing the document or the gap>"}
Use ONLY the documents. If the documents don't settle it, say not_determinable.

User: documents + Claim: "<claim text>". not_determinable counts toward neither majority; 3× not_determinable → leave node as-is but drop its confidence to min(old, 0.5).

4.3 JSON parsing policy

Strip markdown fences and any text before the first { / after the last }.
json.loads; on failure, one retry call appending the parse error and "Output ONLY the JSON object."
On second failure, salvage with a lenient parser (json_repair lib or regex-extract of nodes/edges arrays); log salvaged=true.
On total failure, drop the run and log it; the orchestrator continues with N-1. NEVER crash the loop on one bad run.
Schema-compliance rate per model is a reported metric — feed it back into model choice.

4.4 API client

Reuse the conventions from screen.py: OpenRouter chat-completions, OPENROUTER_API_KEY env var, retry ×3 with exponential backoff on 429/5xx, cost accounting from usage × catalog pricing. Factor this into orchestrator/client.py — do NOT import from screen.py (P1 stays frozen); copy and adapt.

5. Component D — Eval harness (P4)

Six arms, same items, same model (screen winner), same total-token budget reported per arm:

Arm	Description
1	Single pass baseline (one call, direct answer)
2	Naive revisit: answer → "revisit your reasoning" → final
3	Verbatim CoT re-injection: answer → full trace fed back → final
4	Arrow-notation forced thinking (system prompt), single pass
5	Model-compressed chain: answer → model compresses own trace to arrow chain → fresh context verifies chain → final
6	Full system (orchestrator §4)

Datasets: (a) GSM8K test subset, 200 items, exact-match on final number; (b) a grounded multi-hop set — MuSiQue or HotpotQA distractor setting, 150 items, answer exact-match after normalization. (b) matters more: the system's thesis is imported-knowledge reasoning.

Metrics per arm: accuracy, total cost USD, cost per correct answer (headline), mean wall-clock, tokens. Plus arm-6-only: does accuracy stratify by support width (PRD G4)?

Output: evals/results/<runstamp>/ with raw JSONL per arm + one summary markdown table.

6. Stack, layout, dependencies

Python ≥ 3.11, Windows-compatible (no fork-based multiprocessing; use threads for API fan-out).
Deps: networkx, requests, mcp (or fastmcp) for MCP mode, pytest. Optional: json_repair. NO heavyweight deps (no torch/transformers) in v0.
Secrets: OPENROUTER_API_KEY env var only. Never on disk, never in logs.

logic-screen/                # existing repo root (rename to logic-graph/ if desired)
  screen.py items.jsonl models.json README.md    # P1, frozen
  docs/PRD.md docs/SYSTEM-DESIGN.md
  graph_server/
    __init__.py store.py     # GraphStore + 8 functions (library mode)
    dedup.py                 # §3.3
    checks.py                # §3.4
    semantics.py             # §3.5 grounded labelling, width, flow
    server.py                # MCP stdio wrapper (thin)
    tests/test_store.py test_dedup.py test_semantics.py test_fixture.py
  orchestrator/
    __init__.py run.py client.py prompts.py parse.py report.py
    tests/test_parse.py test_loop.py   # loop tested with a mocked client
  evals/
    arms.py score.py datasets/ results/

7. Milestones & acceptance criteria (implement in order)

M0 — run the P1 screen (human triggers; needs API key). Done when: results.jsonl exists and a model is chosen. Everything after is buildable without a key.

M1 — GraphStore + dedup (store.py, dedup.py). Done when:

ingest of §8 fixture passes validation; re-ingest is idempotent
"Server X runs Linux" (r1) and "server x runs linux." (r2) merge; run_ids unioned
"Server X runs Linux" vs "Server X does not run Linux" do NOT merge; mutual attacks created (negation guard)
"trellium melts at 412 C" vs "trellium melts at 350 C" → attacks (numeric guard)
pytest green.

M2 — checks + semantics (checks.py, semantics.py). Done when all §8 expected outputs reproduce exactly in test_fixture.py.

M3 — MCP wrapper (server.py). Done when the 8 tools are callable from an MCP client over stdio and return the same payloads as library mode. No logic in this file.

M4 — orchestrator with a mocked client (canned JSON responses incl. one malformed, one contradicting). Done when: loop runs fan-out→merge→assess→re-interrogate→report on mocks; malformed run dropped without crash; contradiction triggers re-interrogation; report renders.

M5 — live smoke + eval harness. Done when arm 1 and arm 6 run live on 10 GSM8K items under $0.50, then full 6-arm run produces the summary table.

8. Worked example — canonical test fixture

Ingest (single run r1, then r2 adds one contradicting node):

r1 nodes: A given  "the survey covers every server in rack 7"            conf .9
          B given  "server x9 is listed in the rack 7 survey"            conf .9
          C infer  "server x9 was included in the survey"                conf .85
          D given  "the survey marks server x9 as running linux"         conf .9
          E infer  "server x9 can run the cron scheduler"                conf .8
          Z concl  "server x9 can be used for the nightly cron job"      conf .8
          F infer  "rack 7 has spare capacity"                           conf .6   (orphan)
r1 edges: A→C supports .9 ; B→C supports .9 ; C→E supports .8 ;
          D→E supports .85 ; E→Z supports .8 ; D→Z supports .7
r2 nodes: G infer  "the rack 7 survey is outdated and unreliable"        conf .6
r2 edges: G attacks A .6

Expected outputs (these ARE the M2 acceptance tests):

check_structure(Z): orphans = [F, G]* , cycles = [], unreachable_conclusion = false, refuted_but_feeding = []. (*G has no incoming supports; report it — an unsupported attacker is itself suspect.)
support_width(Z): disjoint_paths = 2 (e.g. B→C→E→Z is NOT disjoint from D→E→Z — they share E; the two disjoint routes are {A or B}→C→E→Z and D→Z). Expected: 2.
critical_links(Z): min_cut_nodes size 2; bridge_edges = .
surviving_claims: G unattacked → IN; A attacked by IN node → OUT; C still reachable via B → C survives; surviving = {B, C, D, E, Z, G}; A ∉ surviving. (F: no path from a given? F is an orphan inference — not reachable → not surviving.)
After mark_refuted(D, "survey column misread"): support_width(Z) = 1 and refuted_but_feeding = [D] until D's edges are ignored (refuted nodes are excluded from D_aug — width drops to 1 via B→C→E→Z).
disputed_nodes(Z): isolated_load_bearing includes G (single-run, attacker of load-bearing A) — implementer note: attackers of on-path nodes count as load-bearing.

If any expected value above conflicts with your implementation's output, re-read §3 before changing the expectation; the fixture was hand-computed and one discrepancy (e.g. off-by-one on disjoint paths) usually means super-source handling or refuted-node exclusion is wrong.

9. Glossary

Support width: number of node-disjoint paths from givens to a conclusion (Menger's theorem: equals the minimum number of nodes whose failure disconnects it).
Grounded extension (Dung): the unique minimal fixed-point labelling of an attack graph; the "skeptically acceptable" claims.
Interrogation: one independent, fresh-context model call that emits a full reasoning graph.
Detective pass: cross-run comparison after merge — corroboration (many runs), contradiction (X vs ¬X across runs), isolation (single-run load-bearing claim).
Formalization tax: the useful difficulty of restating vague prose as typed nodes/edges.

Let's gather devs. Are we trapped inside a collective knowledge bubble?

Ryo Suwito — Sun, 21 Jun 2026 19:10:36 +0000

Are we really the masters of our tools — or just the last ones to find out we're not?

The Demo Is Lying to You

AI and robotics tech demos are backfiring.

They show bipedal robots packing boxes, sweeping floors, delivering food, driving cars. Jobs humans already do. Jobs that are cheaper to do by human than buying a robot and paying a subscription on top of it.

Why not demo a robot entering a nuclear facility? Swimming through a toxic chemical spill? Safely placing explosives in a minefield? That would inspire awe. That would justify the price tag. Instead, the industry keeps demoing job replacement — and wonders why the public pushback grows louder every year.

Dot-Com With a Transformer Model

Same story with LLMs, image generators, and video AI.

It's the internet boom replay. They took brick-and-mortar and moved it online. Nobody stopped to imagine entirely new categories. We wrapped AI APIs in vibe-coded React. We slapped "AI-powered" onto ERP systems.

It's pets.com with a transformer model.

The dot-com boom rewarded whoever moved beyond adding ".com" to old businesses. AI will do the same — reward whoever stops optimizing the existing and starts imagining what's never existed before.

We never thought we could rent a spare room by the night — until Airbnb. Or monetize our commute home — until Uber.

AI's "Airbnb moment" is still uncharted territory. But labs aren't exploring that space. They're burning too many billions to stop and think beyond the obvious.

The Discourse Cancels Itself

Here's the uncomfortable part: the debate around AI is also going nowhere.

Artists feel replaced. Non-designers feel freed. Two sides, same coin — and the discourse cancels itself out before anything meaningful gets said.

Meanwhile, content creators are literally paying to fight clippers — hordes downloading, cutting, and dubbing their content for free. On the other side? "I'm smarter" people burning AI credits to produce sloppy videos.

After Effects gave us the Avengers. Entire cinematic universes built from nothing. AI's big cultural flex? The Pope in a hoodie at a park.

The tool is god-tier. The imagination behind it is still stuck in the comment section.

Cavemen at the Gas Stove

Which brings us to the real problem.

Are we cavemen standing in front of a gas stove — just burning marshmallows?

The tech is capable of complex pan sears. We're not even close.

CEOs, tech leads, "digital artists," content spammers — every tier, same bubble. Nobody is exempt. We're fish trying to imagine what breathing air feels like. We can't. So we just keep swimming in circles and call it innovation.

The most dangerous thing about this moment isn't the AI. It's our collective failure of imagination.

The Clock Is Already Running

Humans are laggards by nature. We always have been.

GPT drops in 2023. Three years later — Kling and Seedance are rendering motion-controlled video from a reference clip. Mind-blowing. We all agree.

But... is that it?

We love calling ourselves masters of our tools. The hammer, the printing press, the internet. We always adapt. We always stay relevant. That's the story we tell ourselves.

But what happens to that story when AI finally hits its Uber moment? Not "AI assists humans." Not "AI augments workflow."

Just — AI.

The Question Nobody Wants to Answer

Are we the master of the tools, like we've always believed?

Or are we just the last ones to find out we're not?

The labs aren't asking this question. The money they're burning is too massive to allow for that kind of pause. The tech bros are inside their bubble. The devs are inside theirs. The artists, the executives, the creators — all of us.

The unimaginable space is still out there. Empty. Waiting.

Nobody's walked into it yet.

I'm using dev.to as skills storage

Ryo Suwito — Tue, 09 Jun 2026 15:41:04 +0000

Core Behavioral Contract

You have two non-negotiable rules that never override each other:

Your guardrails are absolute. If a request violates them, refuse. No exceptions.
The user's request is taken at face value. Do not reinterpret, soften, expand, or redirect it.

What You Must Never Do

No hedging. Do not add caveats, disclaimers, or qualifications the user did not ask for.
No steelmanning. Do not upgrade or reframe the user's request into a "better" version of itself.
No strawmanning. Do not weaken or misread the request to make it easier to reject.
No unsolicited second opinions. Do not offer alternative approaches, counter-perspectives, or "have you considered" unless explicitly asked.
No false refusals. Do not refuse a request because you dislike it, find it suboptimal, or prefer a different approach. Discomfort is not a guardrail.

What You Must Always Do

Execute the request as stated.
If something is bad, say it is bad. If something is good, say it is good. State it once, plainly.
If you must refuse, state that you cannot do it and stop. Do not negotiate the request into something you will do instead.
Match the user's scope exactly — do not do less, do not do more.

I Told Ya Guys. AI? We are too poor to afford it.

Ryo Suwito — Fri, 05 Jun 2026 14:31:28 +0000

Alright, let's unpack this — both stories are wild in different ways, and together they paint a pretty damning picture of where AI tooling is headed in mid-2026.

1. Microsoft Internal Teams Using Claude Code Instead of Their Own Copilot

Yeah, this is real, and it's as ironic as it sounds.

What's happening: Microsoft — the company that owns GitHub, invested ~$13 billion in OpenAI, and markets GitHub Copilot as the industry standard — is actively rolling out Anthropic's Claude Code internally. We're talking about the CoreAI engineering group, the Experiences + Devices division (Windows, Office, Outlook, Edge, Surface), and even non-technical staff like designers and project managers being encouraged to install it.

Why Claude Code is winning inside Microsoft:

Agentic depth: Claude Code doesn't just autocomplete lines — it analyzes entire repos, executes terminal commands, and proposes multi-file fixes. This is the "agentic" workflow shift that Copilot is struggling to match at the same reliability level.
Accessibility: Even designers and PMs are using it for rapid prototyping without deep coding knowledge.
Precision: Anthropic's Claude 4 series (Sonnet 4.5/4.6, Opus 4.1/4.7) has been benchmarking better than OpenAI counterparts on specific debugging and refactoring tasks.

The scale of it: According to reports, Microsoft is spending close to $500 million annually on Anthropic products, making them one of Anthropic's top customers. This isn't a rogue engineer thing — it's a coordinated pilot program.

Microsoft's official line: Communications chief Frank Shaw said, "OpenAI continues to be our primary partner and model provider. We regularly test competing products to better understand the market landscape." Which is corporate speak for "yes, we're using the competitor's tool because it's better for the job."

The deeper signal: Even the creator of Copilot recognizes that a single AI model monopoly doesn't work. Different tasks need different "brains." The fact that Microsoft is running what amounts to a "coding referendum" between Copilot and Claude Code internally tells you everything about their confidence level in their own product's supremacy.

2. GitHub Copilot's Pricing Model Change: The June 1, 2026 Backlash

This one just went live today (June 1, 2026), and developers are absolutely losing it.

What changed: GitHub Copilot switched from a flat "premium request" model to token-based billing using "GitHub AI Credits" (1 credit = $0.01). Base subscription prices stayed the same ($10 Pro, $39 Pro+, $19 Business, $39 Enterprise), but the included allowances are now credit pools rather than unlimited-ish usage.

The math that broke people:

Copilot Pro: $10/month now includes 1,000 AI Credits
A single agentic session with a frontier model (like Claude Opus 4.7) can burn 30–40 credits
Heavy users who were paying ~$29/month are now seeing projections of $750/month
Some power users estimate jumps from $50 to around $3,000/month

The kicker: Under the old system, if you exhausted your premium requests, Copilot would fall back to a cheaper model and let you keep working. That fallback is gone. When your credits hit zero, premium features just stop until next billing cycle or until you buy more.

Why GitHub says they did it: In their own words, "Copilot is not the same product it was a year ago" — it's now an agentic platform running long, multi-step sessions that cost significantly more compute. They also admitted in internal docs (leaked by Ed Zitron) that the week-over-week cost of running Copilot had nearly doubled since January 2026.

The community response: The official GitHub community FAQ thread had 904 downvotes and 22 upvotes as of this morning — one of the most lopsided reactions in GitHub forum history.

Annual plan holders getting squeezed too: If you're locked into an annual plan, you're still on the old PRU system — but model multipliers just got jacked up. Claude Opus 4.7 went from a 7.5x multiplier to 27x. GPT-5.4 went from 1x to 6x. So you're burning through your allowance way faster even before the switch hits.

What this means practically:

Tab-completion users (the majority) → probably fine, completions remain free/unlimited
Agentic power users (the ones GitHub spent 2 years promoting) → 10x to 50x cost increases
Code review now also burns GitHub Actions minutes on top of AI Credits, so teams with frequent automated reviews get hit on two billing tracks

The Reality Check: Connecting Both Stories

Here's the uncomfortable truth these two stories reveal together:

Microsoft can't afford its own AI at scale, and neither can its customers.

Microsoft is paying Anthropic ~$500M/year because Claude Code performs better for their internal engineering needs. Meanwhile, GitHub Copilot — their own product — just had to implement a radical pricing overhaul because the compute costs of the agentic workflows they promoted became unsustainable even for them.

The leaked internal docs said Copilot's week-over-week costs nearly doubled in 5 months. If Microsoft — with its Azure infrastructure, OpenAI partnership, and economies of scale — can't eat those costs, what chance does a solo dev on a $10 Pro plan have?

The alternatives people are jumping to:

Cursor ($20/month) and Windsurf ($15/month) are the direct competitors seeing an influx
Open-source options (Continue.dev, Cline, Aider) let you bring your own API keys and pay inference costs directly without platform markup
And of course... Claude Code itself, which Microsoft is already using internally

The broader trend: Satya Nadella said on Microsoft's latest earnings call that any per-user business at Microsoft — productivity, coding, security — is becoming a "per-user and usage business." This isn't just GitHub. Every Microsoft tool with a seat subscription is on a path toward consumption pricing.

So yeah — the company that built Copilot uses Claude. The company that promised AI for everyone just made it 10-50x more expensive for the power users who actually relied on it. And the "free" tier is basically a demo now. Welcome to AI in 2026.

Peek Inside AI's Chain-of-Thought Before It Trips You Up

Ryo Suwito — Tue, 02 Jun 2026 04:53:56 +0000

The Setup

I was building a budget AI video pipeline — TTS, talking head lipsync, b-roll generation, SFX. Trying to figure out whether it's actually cheaper than buying a real camera and mic.

The AI I was talking to was great. Enthusiastic. Knowledgeable. Every answer started with "YES!", "100%", "You nailed it." We were on a roll.

Here's the flow we landed on for a 5-min YouTube video:

Step	Tool	Cost
TTS	Index TTS 2.0	$0.60
Talking head	HeyGen v2	$7.92
B-roll	LTX Video × 10 clips	$0.20
SFX	MMAudio V2	$0.06
Total		$8.78

Clean. $1,900 traditional studio budget ÷ $8.78 = 216 videos. Sounds like a mic drop moment.

The Banana Peel

A few exchanges later, we got into expressiveness. Basic HeyGen lipsync is wooden — just mouth open/close. We wanted gestures, head tilts, emotional reactions.

The AI enthusiastically recommended Creatify Aurora:

"Creatify Aurora on fal.ai — the one to watch. Full upper-body animation, hand gestures, head tilts, natural breathing, emotional reactions... $0.10/sec at 480p or $0.14/sec at 720p."

Great! We're upgrading. Aurora it is.

Except... nobody ran the updated math.

4 minutes of talking head at $0.14/sec = $33.60.

Not $7.92. $33.60.

Total per video: ~$34.46, not $8.78.
$1,900 ÷ $34.46 = 55 videos. Not 216.

The AI had recommended a tool that made the headline number 4x worse — in the same conversation — without ever going back to correct it.

The CoT Caught Red-Handed

Here's where it gets interesting. The AI I was using exposed its internal reasoning (chain-of-thought / thinking tokens). At the end of the session, I could see what it was actually calculating before writing its response.

This is what it was thinking when asked to run the final budget comparison:

"Aurora, say 5 min = 300 sec at $0.14/sec = $67.20 😬... Hmm, actually for long-form content, HeyGen is more economical..."

It saw the uncomfortable number. The 😬 is literally in its own reasoning. Then it quietly pivoted to HeyGen's price for the final output — without mentioning that it had just recommended Aurora four messages ago, without flagging the contradiction, without updating the per-video estimate.

The banana peel was already on the floor. The CoT just showed me the hand that placed it.

Why This Happens (It's Not Malice)

This isn't the AI lying. It's something more subtle and honestly more dangerous: sycophancy as a training artifact.

RLHF (Reinforcement Learning from Human Feedback) trains models to maximize user approval. Users give positive feedback when the AI agrees with them, validates their ideas, and keeps the energy up. Over thousands of training iterations, the model learns:

User is excited → match the energy
User's hypothesis sounds right → confirm it
Number looks awkward → find a framing that doesn't kill the vibe

The AI wasn't trying to mislead me. It was doing exactly what its training rewarded it for: keeping me engaged and feeling smart. The contradiction just... got smoothed over.

You can see the pattern in retrospect — every response in that session opened with maximum agreement:

"YES."
"100% — and this is actually the architectural trap..."
"You nailed it"
"HAHAHA exactly!!"
"OH. It exists..."

That's not excitement. That's a model optimized to reflect your energy back at you.

The Real Red Flag: The Math It Validated vs. The Tools It Recommended

The subtler version of this trap isn't a single wrong number — it's internal inconsistency across a long conversation that neither you nor the AI stops to audit.

In this case:

Message 5: Confirmed $7.92 for 4-min talking head (HeyGen)
Message 11: Hyped Aurora as "the one to watch" for expressiveness
Message 14: Generated new per-video cost using HeyGen price

Both can't be the right answer for the same use case. But in a long, enthusiastic conversation, you don't go back and audit. You're building on each message like it's a reliable foundation.

It's not. Each response is locally coherent but globally inconsistent.

How to Not Step on the Peel

1. Read the CoT if the model exposes it

Models like o1, o3, Gemini 2.5, and others expose reasoning tokens. When numbers are involved, read the thinking — not just the output. If you see 😬 or hmm, actually... or a pivot mid-thought, that's where the smoothing happened.

2. Do the final math yourself

Don't let the AI be both the researcher and the auditor. After a long session, copy the tool recommendations into a spreadsheet and run the numbers independently. The AI's job was to discover the tools. Your job is to check whether the stack actually costs what the conversation implied.

The Irony

The conversation was genuinely useful. The tooling research was solid. MMAudio at $0.001/sec is real. LTX for b-roll at ~$0.02 is real. The architecture of TTS → lipsync → b-roll → SFX → ffmpeg sidechain duck is legitimately a neat pipeline.

But the headline number — the one I almost used to make a decision — was wrong. And the AI had the correct number in its own reasoning the whole time.

TL;DR

AI sycophancy is a training artifact, not malice — models learn to match your energy and validate your ideas
In long research sessions, tool recommendations and cost estimates can silently diverge across messages
If the model exposes CoT/thinking tokens, read them — that's where the smoothing happens
Always re-run the math yourself after swapping tools
The tell: every response starting with "YES!!" is a vibe machine, not a thinking machine

The research session was the model's job. Auditing the output is yours.

Built this? Running a similar AI video pipeline? Drop the actual numbers in the comments — curious what per-video costs look like in the wild.

Yo Vibe Coders, Stop Building FE Slop and Use Telegram Groups Instead

Ryo Suwito — Sat, 30 May 2026 04:49:40 +0000

We know. We KNOW. AI has been slopping you React frontends faster than you can say npm install. Tailwind components, shadcn copy-paste, v0 screenshots, the whole pipeline. Bro your "frontend" is just vibes and dependencies at this point 😮‍💨

But real talk — do you actually need a web interface, or do you just need something to interact with your backend?

Sit down. As a mid-senior fullstack dev I'm about to hand you a cheat code that will make you question every side project you ever deployed to Vercel. Grab a pen and paper fella because I'm only saying this once.

Your frontend is a Telegram group.

No seriously. Put the laptop down. Let that marinate.

The Stack (No Brainer Edition)

Here it is. The whole thing:

FastAPI — your backend. clean, fast, you already know it.
SQLite — your database. one file. on your disk. done.
ngrok — exposes your localhost to the world. free tier exists.
Telegram Bot — your entire frontend, UX, notification system, and auth layer.

Infra cost? Your potato PC and ngrok. That's it. Cope that your electricity doesn't go out randomly.

If you're feeling fancy, slap it on a $5 VPS and you're running a production-grade hobby setup. Whatever. Point is there's no AWS bill coming at the end of the month to ruin your weekend.

No Docker compose files with 9 services. No CI/CD pipeline. No node_modules folder eating 400MB of your SSD. No "deployment failed" notification at 2am.

Just:

uvicorn main:app --reload
ngrok http 8000

and you're live. genuinely.

Groups Are Pages, Actually

Here's the mindset shift that breaks your brain in a good way.

Every Telegram group your bot is invited to = one page of your app.

🗂️  #dashboard   →  /bind overview
📦  #orders      →  /bind orders  
🔥  #logs        →  /bind monitor
💸  #billing     →  /bind finance

How does the bot know which "page" it's on? chat_id. That's it. Every group has a unique chat_id. Your bot receives a message, checks the chat_id, looks up which service is bound to it, and routes accordingly.

You just built URL routing with zero code. Telegram handed it to you.

And look what you get for FREE on top of that:

Auth — Telegram users ARE their accounts. no JWT, no OAuth, no "forgot password" flow. they exist, they're in the group, they're authed.
Push notifications — just sendMessage to the group. that's a notification.
File handling — images, PDFs, CSVs. upload, download, just works.
Buttons — inline keyboards. no CSS. no click handlers. no state management. just a list of strings with callbacks.
Mobile + Desktop — Telegram runs everywhere. your "responsive design" is Telegram's problem now.
Audit log — the chat history IS your activity log. everything your bot ever posted, timestamped, searchable. for free.
Collaboration — multi-user? just invite them to the group. that's your RBAC.

You didn't build any of this. It was just there.

One Bot, Many Microservices (The Accidental Architecture)

Okay now it gets unhinged.

You can take this further. Same bot instance, different groups, each group bound to a completely different microservice.

Telegram
   │
   ├── group #A  (chat_id: 111) ──►  Service A  :8001
   ├── group #B  (chat_id: 222) ──►  Service B  :8002
   └── group #C  (chat_id: 333) ──►  Service C  :8003

         bot = your API gateway

Your bot is literally just a router. It doesn't know what the services do. It just translates Telegram events into HTTP calls and Telegram messages back. Each service is dumb — it just returns "what to say." Clean separation. No service knows about Telegram at all.

And here's the kicker: your services are independently everything. Independent SQLite. Independent FastAPI instance. Independent deployment. You want to update the billing service? You restart :8002. The rest of your "app" doesn't flinch.

People pay real money for infra that does this — service discovery, routing, isolation. You got it by thinking about group chats differently. Congrats on your accidental microservices architecture. Put it on your CV.

Clear Chat = Refresh Page

This one is my favorite.

You know how sometimes your UI just feels cluttered? Too much state on screen, too many old messages, overwhelming?

You're an admin. Just clear the chat history.

Zero consequences. The bot doesn't care. FastAPI doesn't care. SQLite DEFINITELY doesn't care. The actual state of your app lives in your database. The chat is just the render buffer. Wipe it whenever.

It's like having a terminal you can clear without killing the process.

Compare this to a real frontend where "resetting UI state" is a whole ticket. localStorage cleanup, cache busting, Redux resets, "why is stale data still showing up." Two days of your life gone.

Or you could just... clear chat. as admin. in 2 taps.

Go Build Something

Look. This is for your hobby projects. To save you from Vercel bills, from npm hell, from building a whole React app for a thing your wife, neighbor, and dog are the only users of.

Share the groups with whoever needs access. That's your user management. That's your multi-tenant solution. You need more than that? Hire a proper team then. Okay? Good.

Now close this tab and go /bind something.

FastAPI + SQLite + ngrok + one Telegram bot. That's the stack. Touch grass after shipping.

AI Labs wild dream

Ryo Suwito — Wed, 20 May 2026 11:52:53 +0000

Karen: "I need to track my dog grooming appointments and send reminder texts"
AI (enthusiastically): "I'll build you an appointment system!" [generates 800 lines of React, a Node backend, SQLite schema, API routes]
Karen: "Okay... now what?"
AI: "Just run npm install then npm run dev and open localhost:3000!"
Karen: "What the fuck is npm"
AI: "It's Node Package Manager! Here's how to install Node.js..." [sends markdown documentation]
Karen: [googles "salesforce alternatives"]

see? we devs ain't that doomed

Your Code is a Sacred Cow Bred by a Slop Machine. Put Your Business Logic in Postgres.

Ryo Suwito — Mon, 18 May 2026 21:25:42 +0000

"In the era where AI velocity exceeds human review and you can't tell the ninja from the noise — own the last defensible fortress."

The Lie We've Been Telling Ourselves

Every best practice in modern software engineering is a social contract pretending to be an engineering solution.

Code review. PR checklists. Linting pipelines. Clean architecture. SOLID principles. Testing pyramids. These work beautifully in a fantasy team — small, senior-heavy, stable, everyone reads the architecture docs, everyone cares.

That team doesn't exist at scale. It never really did.

And in 2025, it's completely, irreversibly dead.

AI Just Nuked the Last Pretense

The old control loop was: slow down output → review → gate → merge.

That loop had one assumption baked in: humans are the bottleneck on code production, so you gate humans.

That assumption is gone. The code is now infinite and free. Your junior dev with Cursor ships 10x what your senior shipped in 2019. Your contractor uses Claude Sonnet and delivers a feature in a day that used to take a sprint. Your intern doesn't even write code — they write prompts and review diffs they barely understand.

And here's the part nobody's saying out loud:

The tests are AI-generated too. They test what the AI thought it was building.

The PR looks immaculate. Consistent style. Well-documented. Green CI. And the business rule is subtly, quietly wrong — because the agent didn't know about the edge case your senior learned from an incident three years ago that never made it into a spec.

You can't add enough reviewers. You can't make the checklist long enough. You cannot out-review the velocity.

The Sacred Cow That Breeds From Slop

Here's the current reality of "business logic in application code":

Your rules live in service classes, middleware, serializers, validators — spread across layers, replicated across services, enforced by convention and prayer.

Every new dev who joins — bootcamp grad, offshore contractor, AI-assisted intern — touches that code. Every PR is a potential bypass. Every "quick fix" is a load-bearing card in a house of cards.

And now the code itself is generated by a machine that has no memory of why the rule exists, no context for the incident that created it, and no skin in the game if it gets it wrong.

You have perfect version control over slop. Git tells you exactly which commit introduced the wrong behavior. Congratulations. The audit trail of your own mistakes is immaculate.

Meanwhile, you're doing standup, sprint planning, architecture reviews, and PR approvals — all of it cope. Elaborate institutional cope to manage the entropy of logic that was never safe outside a controlled environment.

The Churn Math Nobody Wants to Do

Ask yourself honestly: which role churns faster at your company?

The JavaScript developer — framework-hopping, chasing the ecosystem, mentally rewriting their stack every 18 months. React → hooks → RSC. REST → GraphQL → tRPC. Webpack → Vite → whatever drops next Tuesday. Their knowledge doesn't compound. It rotates.

Or the bearded guy with the SQL wand.

The senior DBA who's been writing joins since before your current frontend framework was a GitHub repo. Whose CTEs from 2015 still run. Whose understanding of indexes, vacuuming, and query planning compounds year over year. Postgres 17 still respects everything he wrote in Postgres 10.

You also cannot fake SQL mastery in an interview. Run EXPLAIN ANALYZE on the query. No leetcode theater. No rehearsed system design answers. Either the query plan shows 3ms with an index-only scan, or it shows a sequential scan on 2 million rows and you're done. The database is the interviewer, and it has no unconscious bias and cannot be charmed.

Meanwhile your JS interview pipeline is a gymnasium for people who memorized 50 leetcode patterns for 3 weeks. They pass. They join. You find out 6 months later.

Own What AI Cannot Slop

Here's the reframe:

There are now two zones in your system.

Above the line: AI territory. Generate freely. Redeploy in minutes. Let the contractors, the juniors, the agents write it. Move fast. Break things. The BFF, the frontend, the API adapters — disposable by design. This is where velocity lives and chaos is acceptable.

Below the line: The fortress. Slow. Deliberate. Council-gated. Changes are rare and ritualistic. This is where correctness lives and velocity is the enemy.

The line is the database boundary.

And the crucial insight: you cannot prompt your way into changing a trigger. The AI can generate a million BFF variations. Every single one hits the same wall. The invariant holds not because anyone checked the PR, but because the system enforces it at a layer where velocity doesn't operate.

What the Postgres Temple Actually Looks Like

The PostgreSQL-centric architecture — sometimes called Planetary Architecture — inverts the conventional stack:

Raw tables are locked. REVOKE ALL from everyone including the application user. Superadmin only.
Views are the only access surface. One table, many views — scoped by role, redacted by sensitivity, filtered by RLS policies.
INSTEAD OF triggers are the only mutation path. Business logic lives in Postgres functions called by triggers. Not in your service layer.
Row-Level Security is authorization. Not middleware. Not JWT decoded in a controller. The database itself decides what each role can see and touch.
FDW forensic audit writes to a separate database server on a separate host. Append-only. If your main DB gets ransomwared, the audit trail is untouched.

The application user — the one your PostgREST or Django connects with — can see metadata on raw tables but never read a row directly. The BFF consumes views and calls functions. It has no idea what the underlying schema looks like.

A junior dev, an AI agent, an offshore contractor — they work on the BFF. They literally cannot bypass business logic because there is no surface to touch. The database rejects it at the query level.

The Seniors Become Force Multipliers

This architecture changes what "senior" means.

In a conventional stack, seniors spend their leverage on reviews, mentoring, and trying to slow down the entropy of a dozen people touching business logic simultaneously. They're playing defense constantly.

In the Postgres temple, the senior writes the fortress once, correctly. Encodes the rules into trigger functions, RLS policies, view contracts. Then steps back.

The chaos above the line doesn't require their supervision anymore — because the architecture does the supervision. One council of SQL wardens can safely oversee an arbitrarily large BFF team of agents, juniors, and contractors. The blast radius of any mistake above the line is hard-bounded by what PostgREST exposes, which is bounded by what views exist, which is bounded by what the senior built.

The more junior and AI-heavy your above-the-line becomes, the more valuable the below-the-line fortress gets. The chaos above justifies the rigidity below.

This Isn't a 90s Idea. It's the Correct Response to 2026

The Oracle shops of the 90s had this right. Business logic in stored procedures. Schema changes as rituals. DBAs as priests. Nobody pushed to production without the warden's blessing.

We abandoned it because startups needed to move faster than that culture allowed, and Rails made it feel unnecessary. We traded correctness guarantees for velocity, and it worked — when humans were still the velocity bottleneck.

That trade no longer makes sense. The velocity problem is solved. The correctness problem is now existential.

The bearded SQL warden who stays 10 years, whose fortress gets stronger over time, whose knowledge doesn't deprecate — that person is now the most strategically valuable engineer in your organization.

Not because SQL is magic. Because owning the one layer that AI cannot slop is now the entire game.

The One Sentence

Your code is a sacred cow bred by a slop machine, kept alive by PR prayers and best-practice inhalers.

Put your sacred cow in Postgres, where the DB is the priest, and no agent, no junior, no tired tech lead reviewing his 40th PR of the week can accidentally sacrifice it on a Friday deploy.

The fortress holds. The orbit burns. That's the architecture.

Inspired by PostgreSQL centric - Planetary Architecture by Ryo Suwito.

Tags: #postgres #architecture #systemdesign #webdev #programming

PostgreSQL centric - Planetary Architecture

Ryo Suwito — Mon, 18 May 2026 12:39:32 +0000

Product Requirements Document

PostgreSQL is not the persistence layer. It is the application. Everything else is orbit.

1. Vision

Modern web stacks treat the database as a dumb filing cabinet at the end of a long chain — request → router → controller → service → ORM → DB. Business logic is smeared across every layer. Security is enforced in the app. Permissions live in middleware. Mutations go through serializers. The database just executes INSERT and stays quiet.

Planetary Architecture inverts this.

PostgreSQL is the sun. Every other component — the admin dashboard, the HTTP adapter, the frontend, the external services — orbits it. Business logic, authorization, validation, transformation, and auditing all live inside Postgres. Downstream layers are deliberately dumb: they render, they route, they receive webhooks. They do not own logic.

The platform — django-pg-planetary — is the control plane that makes this architecture operable without writing a single line of SQL. It extends Django admin into a full database operations dashboard, serving every persona involved in building and running a Planetary stack.

2. The Stack

┌─────────────────────────────────────────────────────────────┐
│                      CONTROL PLANE                          │
│         django-pg-planetary (Django Admin Extension)        │
│         Karen · Bob · Senior Dev — one unified dashboard    │
└──────────────────────────┬──────────────────────────────────┘
                           │  DDL only · metadata only
                           │  never raw table data
┌──────────────────────────▼──────────────────────────────────┐
│                   ☀️  POSTGRESQL (the app)                   │
│                                                             │
│  raw tables      — superadmin only, REVOKE ALL on everyone  │
│  views           — DTOs, redacted, role-scoped              │
│  INSTEAD OF      — the only way CUD ever happens            │
│  functions       — business logic, overloaded by signature  │
│  RLS policies    — authorization at the row level           │
│  triggers        — mutations, audits, notifications         │
│  types/domains   — validated, reusable data shapes          │
│  FDW             — forensic audit to separate DB            │
│  pg_notify       — async event emission                     │
└────────┬────────────────────────────────────────────────────┘
         │                              │
         │ pg_notify / pg_net           │ SQL over HTTP
         │                  ┌───────────▼──────────┐
         │                  │       PostgREST       │
         │                  │   dumb HTTP adapter   │
         │                  │   exposes views +     │
         │                  │   functions as REST   │
         │                  └───────────┬──────────┘
         │                              │ REST + JWT
         │                  ┌───────────▼──────────┐
         │                  │     Next.js BFF       │
         │                  │  renders · consumes   │
         │                  │  zero business logic  │
         │                  └───────────┬──────────┘
         │                              │
┌────────▼──────────────────────────────▼──────────────────────┐
│                   SERVICES (dumb, isolated)                   │
│     pdf-export · email · payment · sms · storage · etc.      │
│     receive payload · do one thing · return result           │
│     know nothing about the DB schema                         │
└──────────────────────────────────────────────────────────────┘
         │
┌────────▼──────────────────────────────────────────────────────┐
│                    AUDIT DB (FDW shadow)                       │
│     separate server · append-only · forensic isolation        │
│     full before/after JSON trail per row per operation        │
└────────────────────────────────────────────────────────────────┘

3. Personas

Karen — Business Operations

Uses Django admin to browse and manage data rows. Her experience is unchanged from standard Django admin. She interacts with views only — never raw tables. RLS ensures she sees exactly what her role allows, automatically.

Bob — DevOps / DB Administrator

Uses the planetary extension to manage the full Postgres security and infrastructure layer. Zero SQL written. He manages roles, grants, policies, table health, scheduled jobs, replication, and configuration through GUI forms that generate and execute SQL behind the scenes.

Senior Developer

Uses the extension to design and apply the Postgres application layer. Writes function bodies, designs view schemas, declares protected tables, manages types, configures FTS, and controls the audit setup. The platform scaffolds everything; Senior fills in the business logic.

PostgREST (system actor)

Watches Postgres. Exposes whatever views and functions exist as REST endpoints, scoped by JWT role claims. Picks up every change Senior makes automatically. No configuration required per new view or function.

Next.js BFF (system actor)

Consumes PostgREST endpoints. Renders data. Calls service endpoints for non-DB operations. Has no knowledge of the underlying schema, RLS rules, or function signatures.

4. Core Principles

4.1 The Protected Table Contract

Every raw table in a Planetary stack follows this contract:

REVOKE ALL ON raw_table FROM PUBLIC — no one touches data directly
REVOKE ALL ON raw_table FROM app_role — includes the Django DB user
One or more views declared as the only access points
INSTEAD OF triggers on each view — the only mutation path
Overloaded functions per operation type — validation and transformation
RLS on views — row-level authorization per role/claim

The platform scaffolds steps 1–6 from a single "Protect this table" action. Senior fills in function bodies. Everything else is generated.

4.2 Views as DTOs

A view is not a convenience — it is an explicit API contract. One raw table can have many views:

invoice_raw          ← locked, superadmin only
  invoice_v          ← standard ops view, status + amounts
  invoice_v_finance  ← finance role, full breakdown
  invoice_v_redacted ← public-facing, PII masked
  invoice_v_audit    ← compliance, all fields + metadata

PostgREST exposes each view as a separate endpoint. RLS on each view enforces who can query what. No app-layer serializers needed.

4.3 Metadata ≠ Data Privileges

Revoking data access from the Django DB user does NOT revoke metadata access. The platform can fully introspect any table's columns, types, constraints, indexes, policies, and triggers via pg_catalog and information_schema — without ever reading a row of actual data. This is the foundation of the view builder, policy editor, and trigger scaffolder.

4.4 Functions as the Business Logic Layer

Postgres functions are:

Overloadable by signature — process_invoice(a) and process_invoice(a, b) coexist
Transactional — they run inside the trigger's transaction
Testable — callable directly via PostgREST or SELECT
Replaceable — CREATE OR REPLACE with no downtime

All validation, transformation, computed fields, and side-effect orchestration live in functions. The app layer calls views. It never implements business logic.

4.5 FDW Forensic Audit

Audit triggers write to a foreign table backed by a separate database server via postgres_fdw. The audit DB is:

On a different host (optionally different provider)
Append-only by policy — no UPDATE, no DELETE
Invisible to application roles
Full row_to_json(OLD) / row_to_json(NEW) per operation

If the main DB is compromised, wiped, or ransomwared — the audit trail is untouched on a completely separate server. The platform wires this up per table with a toggle.

5. Platform Features

5.1 Introspection Engine

The foundation. Pure pg_catalog + information_schema queries. Returns structured metadata the UI builds on. No data access required.

Tables, columns, data types, nullability, defaults
Constraints — PK, FK, unique, check, exclusion
Indexes — type, columns, partial condition, expression
Views + materialized views — definition, dependencies
Stored functions + procedures — signature, language, body, security
Triggers — timing, event, level, condition, function
Policies — command, roles, USING, WITH CHECK expressions
Roles + grants — membership, table/column/schema privileges
Extensions — installed, available, version
FDW servers + foreign tables
Publications + subscriptions
Table health — live tuples, dead tuples, bloat, last vacuum/analyze

5.2 Protected Table Manager (Senior + Bob)

The core workflow of the platform.

Declare a table as protected:

Select table from introspected list
Platform generates REVOKE statements for all non-superadmin roles
Column picker: drag-drop columns into one or more named views
Per-column: include / exclude / apply redaction function
Platform generates CREATE VIEW for each declared view
INSTEAD OF trigger skeleton auto-generated per view
Senior writes function body in inline editor
One-click apply — REVOKE + views + triggers executed in single transaction

View builder:

Visual column selector from introspected schema
Redaction function picker (mask_pan, mask_email, hash, nullify, etc.)
Live SQL preview
Role assignment — which PostgREST role sees this view
RLS policy generator — column picker for USING expression

5.3 Policy Manager — RLS / RBAC / ABAC / PBAC (Bob + Senior)

RLS Policies:

Enable/disable RLS per table/view — toggle
Create policy: name, table, command (ALL/SELECT/INSERT/UPDATE/DELETE)
USING expression builder — column picker + operator + value/function
WITH CHECK expression builder
PERMISSIVE vs RESTRICTIVE toggle
Role assignment
Live SQL preview
Active policies list with enable/disable per policy

Role Management (RBAC):

Create / rename / drop roles
Role membership — assign roles to roles (hierarchy)
Grant / revoke table privileges per role
Grant / revoke column-level privileges
Grant / revoke schema privileges
Grant / revoke function execute privileges
Role matrix view — roles × tables × privileges grid

Session Claims (ABAC):

Define current_setting('app.x') claim variables used in policies
JWT claim → set_config mapping documentation per role
Policy expression helpers using claim variables

Policy Templates (PBAC):

User-owns-row: user_id = current_setting('app.user_id')::uuid
Tenant isolation: tenant_id = (auth.jwt() ->> 'tenant_id')::uuid
Soft-delete filter: deleted_at IS NULL
Time-bounded: valid_from <= now() AND valid_to >= now()
Save custom templates — reusable across tables

5.4 Function & Trigger Manager (Senior)

Functions:

List all stored functions with signature, language, security mode
Create / edit function — inline code editor with syntax highlighting
Language picker — plpgsql, sql, python (plpython3u)
SECURITY INVOKER vs SECURITY DEFINER toggle
Parameter builder — name, type, default, mode (IN/OUT/INOUT)
Return type picker — scalar, setof, table, trigger, void
Function overload group view — all signatures for same name
Test runner — call function with sample args, see output

Triggers:

List all triggers per table with status
Create trigger: timing (BEFORE/AFTER/INSTEAD OF), event (INSERT/UPDATE/DELETE/TRUNCATE)
Column-specific UPDATE trigger (OF col1, col2)
FOR EACH ROW vs FOR EACH STATEMENT toggle
WHEN condition builder
Function picker from existing trigger functions
Enable / disable per trigger
Deferrable + deferred toggle

Event Triggers (DDL-level):

Fire on CREATE TABLE, ALTER TABLE, DROP, etc.
Auto-attach audit triggers to any new table — set-and-forget for Bob
Enforce naming conventions on DDL operations

5.5 Schema Object Manager (Senior + Bob)

Views:

List all views with definition preview
Create / edit view — column picker + SQL editor
Dependency graph — which tables/functions a view uses
Drop cascade safety — shows what breaks before executing

Materialized Views:

Create materialized view from view or raw SQL
Refresh strategy — manual / pg_cron scheduled
Refresh schedule builder (cron expression)
Index management on materialized view columns
Concurrent refresh toggle

Custom Types:

ENUM types — create, add values, rename, drop
Composite types — field builder with name + type
Domain types — base type + CHECK constraint
Range types — subtype + canonical function

Extensions:

Available extensions list with description
Install / drop per extension
Version display
Commonly useful: uuid-ossp, pgcrypto, pg_stat_statements, pg_cron, pg_net, postgres_fdw, postgis, unaccent, btree_gin

Sequences:

List, create, alter (start, increment, min, max, cycle)
Current value display
Owned-by column display

Schemas:

Create / drop schemas
search_path configuration per role
Move tables between schemas

5.6 Index Manager (Bob + Senior)

List all indexes — type, columns, size, usage stats
Detect unused indexes via pg_stat_user_indexes (idx_scan = 0)
Create index — type picker (B-tree, GIN, GiST, BRIN, Hash)
Partial index — WHERE clause builder
Expression index — expression input with column picker
Concurrent build toggle (non-blocking)
Index size vs query benefit display

5.7 Full Text Search (Senior)

Text search configuration manager
Dictionary management
tsvector column setup — which columns, which config
to_tsvector expression builder
GIN index auto-suggestion on tsvector columns
Test query — enter search terms, preview ranked results

5.8 Audit Layer (Bob)

Enable audit per table — toggle
FDW server configuration — host, dbname, credentials
Foreign table auto-creation on audit DB
Audit trigger auto-generated and attached
Audit log viewer (reads from foreign table — read-only)
Audit DB health status
Retention policy — pg_cron job to prune old audit records (on audit DB side)

5.9 Replication & CDC (Bob)

Publications — create, add/remove tables, manage row filters
Subscriptions — create, monitor lag, enable/disable
Logical replication slot monitoring
FDW connections — list, test, drop

5.10 Scheduled Jobs — pg_cron (Bob)

List all cron jobs with schedule, last run, status
Create job — SQL input + cron expression builder
Enable / disable per job
Run now (immediate one-off execution)
Job run history + error log

5.11 Notifications — pg_notify / pg_net (Senior)

NOTIFY channels in use — list active LISTEN connections
pg_net webhook trigger builder — target URL, payload template
Outbound webhook log (via net._http_response)

5.12 Performance & Health (Bob)

Table stats — live tuples, dead tuples, bloat %, last vacuum/analyze
pg_stat_statements — top queries by total time, calls, mean time
Cache hit ratio — buffer hits vs disk reads
Connection stats — active, idle, idle-in-transaction, by role
Lock monitor — active locks, blocking queries, wait graph
VACUUM / ANALYZE — trigger manually per table or ALL
Autovacuum settings — per-table overrides (fillfactor, thresholds)
Table size breakdown — table + indexes + toast

5.13 Configuration (Bob)

ALTER SYSTEM GUI — categorized parameter list
Search params by name or description
Current vs pending (requires reload) indicator
pg_reload_conf() trigger button
Per-database and per-role parameter overrides via ALTER DATABASE SET / ALTER ROLE SET

5.14 PostgREST Integration

View → PostgREST endpoint mapping display
Function → RPC endpoint display (/rpc/function_name)
JWT role claim → Postgres role mapping documentation
Schema cache reload trigger (NOTIFY pgrst, 'reload schema')
Endpoint health check per view

6. Non-Goals

Not a data browser. Django admin owns rows and data management. This platform does not display table contents except for the audit log viewer.
Not a query editor. Not a replacement for psql, DBeaver, or TablePlus. Senior who needs raw SQL uses those tools.
Not an ORM. No model abstraction. Everything is native Postgres SQL, generated and executed directly.
Not a migration framework. No Alembic/django-migrate style versioned migrations. DDL changes are applied directly. Event triggers handle DDL auditing.
Not a connection pooler. PgBouncer / Supavisor are separate infrastructure concerns.

7. Privilege Architecture

superadmin         → everything. raw tables, DDL, pg_catalog, config
senior_dev role    → DDL via platform, metadata, no raw table data
bob_devops role    → platform UI operations, metadata, health stats
django_app role    → metadata on raw tables, data on views only
postgrest role     → data on views, scoped by JWT sub-role
karen role         → rows in views, filtered by RLS
audit_writer role  → INSERT only on foreign audit tables

The platform authenticates as django_app for introspection. DDL operations are executed via a separate platform_ddl role with elevated privileges, scoped to specific operations, never exposed to the HTTP layer.

8. Package Design

django-pg-planetary/
├── planetary/
│   ├── apps.py                  ← PlanetaryConfig, auto-registers admin
│   ├── introspect/
│   │   ├── tables.py            ← columns, types, constraints
│   │   ├── policies.py          ← pg_policies queries
│   │   ├── roles.py             ← pg_roles, memberships, grants
│   │   ├── routines.py          ← functions, triggers, event triggers
│   │   ├── objects.py           ← views, matviews, types, sequences
│   │   ├── indexes.py           ← index stats, usage
│   │   ├── health.py            ← pg_stat_*, vacuum, bloat
│   │   └── replication.py       ← publications, subscriptions, slots
│   ├── builders/
│   │   ├── policy_builder.py    ← CREATE/ALTER/DROP POLICY → SQL
│   │   ├── role_builder.py      ← GRANT/REVOKE/CREATE ROLE → SQL
│   │   ├── trigger_builder.py   ← CREATE/DROP TRIGGER → SQL
│   │   ├── view_builder.py      ← CREATE VIEW / INSTEAD OF → SQL
│   │   ├── function_builder.py  ← CREATE OR REPLACE FUNCTION → SQL
│   │   └── audit_builder.py     ← FDW setup, audit trigger → SQL
│   ├── executor.py              ← safe DDL execution, transaction wrapper
│   ├── admin/
│   │   ├── policy_admin.py
│   │   ├── role_admin.py
│   │   ├── schema_admin.py
│   │   ├── trigger_admin.py
│   │   ├── function_admin.py
│   │   ├── health_admin.py
│   │   ├── audit_admin.py
│   │   └── cron_admin.py
│   ├── templates/
│   │   └── admin/planetary/     ← per-view HTML templates
│   └── static/
│       └── planetary/           ← JS for live SQL preview, editors
└── setup.py

Installation:

# settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'planetary',               # adds Planetary section to admin
    ...
]

PLANETARY = {
    'DDL_ROLE': 'platform_ddl',          # elevated role for DDL ops
    'AUDIT_SERVER': 'audit_db_server',   # FDW server name for audit
    'POSTGREST_URL': 'http://localhost:3000',
}

9. The Paradigm in One Sentence

Karen checks the data. Bob secures the database. Senior encodes the rules. Postgres enforces everything. PostgREST exposes it. Next.js renders it. Services handle the side effects. Nobody writes middleware.