Open Forem

Postgres Tells You Your Query Was Slow. Not Which Index Was Wasted.

Ali Afana — Sat, 09 May 2026 11:45:42 +0000

TL;DR: Postgres has pg_stat_user_indexes. It tells you how many times each index was scanned. It does not tell you whether the slow query you're chasing actually used the index you added for it, or whether you're maintaining indexes the planner never picks. I built a 3-file analyzer — a query wrapper, a logs table, a dashboard — and the first time I ran it against my own production database, 20 of my 51 indexes had never been scanned. 78% of my total index disk was being maintained for nothing.

The Gap in Postgres's Stats

Open pg_stat_user_indexes right now:

SELECT indexrelname, idx_scan, idx_tup_read, idx_tup_fetch
FROM pg_stat_user_indexes
WHERE schemaname = 'public';

You'll see one row per index:

idx_scan — how many times the index was used
idx_tup_read — tuples read via the index
idx_tup_fetch — tuples fetched from the heap after the index hit

That's it.

You won't see:

Which queries used which index
Whether the slow query you wrote a CREATE INDEX for is actually using it
How much each unused index is costing you per INSERT
Whether the planner picked your composite index over a single-column one (and made the single-column one redundant)
Plan diffs when the same query starts going through a different index next week

For a hobby project, fine. For a production database with hot tables, you're guessing.

I'm building a multi-tenant AI sales chatbot. The schema has 51 indexes spread across stores, products, conversations, messages, leads, webhook logs, and the rest of the tables. Some I added intentionally. Some came along with migrations as scaffolding. Some I'd genuinely forgotten about. I had no idea which ones were earning their keep.

pg_stat_user_indexes told me idx_conversations_store_id had been scanned 13 times this month. That number was useless on its own. Was it the chat handler? The merchant dashboard? The webhook? Did the planner pick it because it was the only viable plan, or because a composite index that's already on the table would have done the same job for free? No way to know.

So I built my own observability. Three files. One afternoon.

File 1: The Wrapper (`query-logger.ts`)

The core idea: don't run queries directly. Run them through a wrapper that captures the plan, measures execution, and logs everything asynchronously.

Why Not pg_stat_statements or auto_explain?

I started with pg_stat_statements and auto_explain. The first gives you per-query stats but not plans — it tells you a query is slow without telling you which index the planner picked. The second writes plans to the Postgres log, which means parsing log files instead of querying a table. I wanted plans + dimensions in one row I could JOIN against pg_stat_user_indexes. Hence the wrapper.

EXPLAIN Without ANALYZE

EXPLAIN (FORMAT JSON) returns the planner's chosen plan without executing the query. Cost is sub-millisecond for most queries. It gives you a tree of nodes — Index Scan, Bitmap Heap Scan, Seq Scan — each tagged with the relation and the index it touches.

// Last checked against Postgres 16 — https://www.postgresql.org/docs/current/sql-explain.html
async function getPlan(sql: string, params: unknown[]) {
  const result = await db.query(`EXPLAIN (FORMAT JSON) ${sql}`, params);
  return result.rows[0]["QUERY PLAN"][0];
}

function extractIndexes(plan: any): string[] {
  const indexes: string[] = [];
  const walk = (node: any) => {
    if (node["Index Name"]) indexes.push(node["Index Name"]);
    (node["Plans"] ?? []).forEach(walk);
  };
  walk(plan["Plan"]);
  return indexes;
}

function planContainsSeqScan(plan: any): boolean {
  let found = false;
  const walk = (node: any) => {
    if (node["Node Type"] === "Seq Scan") found = true;
    (node["Plans"] ?? []).forEach(walk);
  };
  walk(plan["Plan"]);
  return found;
}

The Wrapper

import { db } from "@/lib/db";
import { supabaseAdmin } from "@/lib/supabase/admin";

interface QueryMeta {
  endpoint: string;
  tableName: string;
  storeId?: string;
}

export async function loggedQuery(
  sql: string,
  params: unknown[],
  meta: QueryMeta
) {
  const plan = await getPlan(sql, params);

  const start = Date.now();
  const result = await db.query(sql, params);
  const duration = Date.now() - start;

  // Fire-and-forget log — never blocks the response
  supabaseAdmin
    .from("query_logs")
    .insert({
      query_hash: hash(sql),
      sql_preview: sql.slice(0, 200),
      table_name: meta.tableName,
      endpoint: meta.endpoint,
      store_id: meta.storeId,
      indexes_used: extractIndexes(plan),
      seq_scan: planContainsSeqScan(plan),
      planning_ms: plan["Planning Time"],
      execution_ms: duration,
      rows_returned: result.rowCount,
    })
    .then(() => {})
    .catch(() => {}); // Silent fail — monitoring never breaks the app

  return result;
}

(hash(sql) is SHA-1 over the SQL string with $1, $2, etc. stripped via regex — "same query, different parameters" collapses into one group.)

The One Pattern That Matters: Fire-and-Forget

Same rule as every other observability layer:

.then(() => {}).catch(() => {}); // Silent fail

The log insert is not awaited. If the database is overloaded, if the table is locked behind VACUUM, if the row blows up some constraint — the user-facing query still goes through.

In testing, the log insert takes 8–25ms. The actual query takes 5–800ms. If I awaited the log, on a cheap read I'd literally double the latency for zero user benefit.

Monitoring must never slow down the thing it's monitoring. That's the only rule that matters here.

There's a second cost worth naming: EXPLAIN plans the query, then the actual db.query plans it again. Two plans per measurement. For most queries it's microseconds. For planner-heavy queries with lots of joins, it adds up. Solution: sample. I run the wrapper on 1 in 10 queries, controlled by an env var. Enough signal, low overhead.

File 2: The Table (`query_logs`)

CREATE TABLE query_logs (
  id BIGSERIAL PRIMARY KEY,
  query_hash TEXT NOT NULL,
  sql_preview TEXT,
  table_name TEXT,
  endpoint TEXT,
  store_id UUID,
  indexes_used TEXT[],
  seq_scan BOOLEAN DEFAULT false,
  planning_ms NUMERIC(10,3),
  execution_ms INT,
  rows_returned INT,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_query_logs_hash ON query_logs(query_hash);
CREATE INDEX idx_query_logs_created ON query_logs(created_at);
CREATE INDEX idx_query_logs_indexes_used ON query_logs USING GIN (indexes_used);

The columns are the dimensions. Each one answers a question Postgres's stats can't:

query_hash — group identical queries. The same chat-search query with different store_id is one logical query. Hash the SQL with parameters stripped.
indexes_used — array of index names the planner picked. The GIN index lets you ask "show me every query that touched idx_products_store_id" in milliseconds.
seq_scan — true if the plan contains a Seq Scan node. Fast filter for "queries that fell off the index entirely."
planning_ms + execution_ms — separate them. A query with 50ms planning and 5ms execution is a different problem from 5ms planning and 50ms execution.
rows_returned — combined with execution time, surfaces queries where the index scan retrieved 100k rows just to filter down to 12.

One detail that's easy to miss: indexes_used as TEXT[], not TEXT. A single query can scan three indexes (composite + bitmap OR + index-only scan). Store it as a comma-separated string and you'll spend the rest of your life writing LIKE '%idx_name%' queries. Use the array. Use the GIN index. Move on.

File 3: The Dashboard

The killer query — the one that makes this whole exercise worth the afternoon — is the join you've been waiting for. Indexes that exist in Postgres, never appear in any logged plan:

WITH plan_indexes AS (
  SELECT DISTINCT unnest(indexes_used) AS index_name
  FROM query_logs
  WHERE created_at > now() - interval '30 days'
)
SELECT
  s.indexrelname AS index_name,
  s.relname AS table_name,
  pg_size_pretty(pg_relation_size(s.indexrelid)) AS size,
  s.idx_scan AS pg_scan_count,
  CASE WHEN p.index_name IS NULL
    THEN 'NEVER PLANNED'
    ELSE 'used'
  END AS status
FROM pg_stat_user_indexes s
LEFT JOIN plan_indexes p ON p.index_name = s.indexrelname
WHERE s.schemaname = 'public'
ORDER BY pg_relation_size(s.indexrelid) DESC;

That's it. That's the question Postgres can't answer alone: which of my indexes does the planner never pick over a real workload window?

The other views I added on top of query_logs:

Slowest query groups — query_hash ordered by avg(execution_ms), with indexes_used displayed alongside. Now "this query is slow" becomes "this query is slow and it's using idx_X — is idx_X doing what I thought?"
Queries that fell to Seq Scan — WHERE seq_scan = true, grouped by query_hash. Often the index you added doesn't match the predicate exactly (wrong column order, missing WHERE clause).
Index swap candidates — pairs of indexes where one is a strict prefix of another. The shorter one is usually dead weight.
Planning time spikes — queries where planning_ms > execution_ms. Almost always a sign the planner is fighting too many indexes on the table.

The UI is intentionally boring. Stat cards: total queries logged, distinct query shapes, % seq-scan, count of indexes never planned. A table per view. No charts that take longer to read than the underlying number.

What It Found

Real numbers, the day I built the dashboard:

Metric	Value
Total indexes (public schema, excluding primary keys)	51
Indexes with `idx_scan = 0`	20
Indexes with `idx_scan` between 1 and 50	8
Total index disk	3,720 kB
Disk used by never-scanned indexes	2,896 kB (78%)

Read that last row again. Of the disk Postgres was using for indexes on this database, 78% of it was sitting on b-trees the planner had never once chosen.

Pre-launch is exactly the right time to build this lens. The 78% is real, and the makeup is honest: roughly half of the zero-scan indexes are on a paused workspace whose feature isn't running, four more are on Messenger-related tables still gated behind Meta's app review. Those will earn their keep eventually. The rest — and the boundary cases sitting at 2 or 14 scans — are the actual question. The dashboard's job today isn't to drop anything. It's to give me a queued list to revisit 30 days after the product takes real traffic, when "zero scans" means waste and not "feature hasn't shipped." That list took one afternoon to build. The point isn't the headline number — it's that without the lens, I couldn't have separated dormant from wasted at all.

The 2,552 kB Index Nobody Has Ever Used

The single most surprising finding: idx_products_embedding, the pgvector index for semantic search, is 2,552 kB on its own — 94% of the index disk on the products table, and around two-thirds of the entire database's index disk. The planner has never once chosen it.

Semantic search hasn't run at production volume yet — chat is gated to admins until Meta clears the Messenger app — so this isn't waste, it's a dormant feature. But that's exactly what makes the dashboard valuable. The day customers start chatting at scale, this index either lights up or it doesn't, and I'll know within hours whether semantic search is actually using it or quietly falling back to ILIKE.

The Barely-Used Tier

idx_conversations_store_id at 13 scans, idx_leads_store_id at 14, idx_products_status at 4, idx_webhook_logs_store_id at 2. These are the boundary cases — indexes the planner has picked once or twice and otherwise ignored. They're the exact set worth watching: some will graduate to actively used as traffic grows, others will sit at 14 scans for the next month and join the drop list.

That's the loop. pg_stat_user_indexes tells you how many times each index was scanned. It can't tell you whether each scan was the only way the query could have run, or whether the zero-scan indexes are dormant scaffolding or genuine waste. Without a dashboard like this you can't even ask the question.

5 Things I Learned Building This

1. Index stats don't equal index value

idx_scan = 0 is a candidate, not a verdict. On a mature database, it usually does mean drop. On a young one, it means "the planner has never picked this yet" — could be redundant, could be dormant scaffolding for a feature you haven't shipped. Either way, treat it as a question. And idx_scan = 50,000 doesn't mean an index is earning its keep either; if a sibling index would have been picked instead, the high scan count is just an artifact of which one the planner sorted first. Plans tell the truth. Stats tell you what the planner did, not what it could have done without you.

2. EXPLAIN without ANALYZE is your friend

EXPLAIN ANALYZE runs the query. EXPLAIN alone just plans it. The plan is what you usually want. Reach for ANALYZE when you specifically need actual row counts vs. estimates — but for "which index would the planner pick for this," EXPLAIN alone is enough and orders of magnitude cheaper.

3. Sample — don't measure every query

Wrap every query and your monitoring becomes a meaningful fraction of your DB load. For index usage — fundamentally a frequency question — 10% sampling captures ~99% of the signal at 10% of the cost. Confidence intervals on aggregate stats stay tighter than the noise floor you're chasing anyway. Tail-latency hunting is the exception: chasing the slowest 1% of queries needs higher sampling or full coverage. For "which indexes does the planner pick," 10% is plenty.

4. The dimensions are the product

Same lesson as every other observability piece I've written. query_logs only answers questions you thought to ask when you designed the schema. endpoint, table_name, seq_scan, indexes_used as a typed array — each column is a question you'll get to ask cheaply later. Add them when you build, not when you have a problem.

5. Indexes are a cost, not a feature

Every secondary index has to be updated on every INSERT and on every UPDATE that touches its columns. On a hot table with 8 indexes, that's up to 8 b-tree maintenance operations per write. Most teams treat CREATE INDEX as free because the read got faster now. The cost shows up six months later in INSERT latency that nobody traces back to "we added an index for that one report."

What to Add When You're Ready

Plan diff over time. Same query_hash, different indexes_used today vs. last week is a regression alarm. Cardinality changed. Statistics went stale. ANALYZE didn't run.

Cost-of-write per index. Multiply each table's INSERT/UPDATE rate by the number of indexes that touch the modified columns. Indexes on rarely-modified columns are nearly free. Indexes on hot-update columns are budget items.

Bloat tracking. pg_stat_user_indexes doesn't tell you when an index is fragmented and needs REINDEX. Add a column tracking the ratio between live tuples and index size — a sudden divergence is almost always bloat.

Seq Scan threshold alerts. A query that flips from Index Scan to Seq Scan in production is usually a missing or stale index. Catch it the day it happens, not the day the table grows enough to make it user-visible.

Counterfactual planning. Run the same query with SET enable_indexscan = off and compare plan costs. If the cost barely moves, the index is decorative.

The Bottom Line

Three files. One afternoon. About 350 lines.

A query wrapper that captures plans. A table with the dimensions you need to slice by. A dashboard that joins query plans to index stats — because that join is the question Postgres structurally cannot answer on its own.

You don't need pgBadger or pganalyze (those are great if you have the budget). You need the smallest possible instrument that answers "which of my indexes does the planner never actually pick" — because that's the question your pg_stat_user_indexes view can't.

The first time I ran mine, it told me 20 of 51 indexes had never been scanned, and 78% of my index disk was being maintained for nothing. Some of that is pre-launch noise. Some of it isn't. I now have a queued list of indexes to revisit 30 days after the product takes real traffic — and I have it because I built the lens before I needed it.

Build the lens before you ship. The schema is simplest now, and the question "which of these indexes will the planner actually use?" is one your future self will pay to answer if you don't pay to answer it cheaply today.

I'm building **Provia* — an AI sales chatbot for Arabic-speaking e-commerce stores. Follow for more posts on building AI products from Gaza on a tight budget.*

I Built These Tools Because the Frustration Was Real

Sushil Kulkarni — Sat, 09 May 2026 11:43:48 +0000

Most side projects don’t start with inspiration.

They start with irritation.

A repeated task.
A broken workflow.
A problem you keep telling yourself you’ll “fix later.”

That’s how all of mine started.

Not with a grand plan.
Just friction I couldn’t ignore anymore.

1. TermiCool — Because Terminal Customization Shouldn’t Feel Like Surgery

Customizing my terminal was taking way more time than it should.

Editing config files.
Hunting hex codes.
Tweaking themes.
Accidentally breaking everything.

Something that should take 30 seconds was eating hours.

I wanted:

one click to apply a theme
one click to undo it
zero risk of breaking my setup

So I built TermiCool.

Simple, fast, reversible terminal theming without the usual pain.

2. TreePress — Because PDF Export Shouldn’t Destroy Your Work

Exporting to PDF was worse.

Code lost syntax highlighting.
Markdown lost formatting.
HTML dashboards broke completely.

And tabs?
Especially painful.

PDF has no concept of tabs, so content hidden behind tabs would simply disappear.

Half the page gone.

That made exports useless for real documentation.

I needed exports that looked like what I actually built—not a flattened, broken version of it.

So I built TreePress.

Now it creates:

pixel-faithful exports
searchable PDFs
tab-aware rendering
proper HTML + Markdown support
predictable output without manual fixing

No config.
No surprises.

3. CCL — Because Rebuilding Claude Code Setup Was Repetitive

Every new project meant rebuilding the same Claude Code setup.

Same files.
Same folder structure.
Same configuration.

Again.
And again.

It felt like setup work pretending to be productivity.

So I built CCL.

Now I run one command and get:

CLAUDE.md
subagents
skills
security hooks
project-aware scaffolding

All generated around the actual codebase.

Done in seconds.

None of This Was Planned

These weren’t startup ideas.

They were problems I got tired of tolerating.

They were built in stolen hours:

late nights after work,
early weekend mornings,
small windows between real life and responsibilities.

That’s how most side projects actually happen.

Not in perfect focus.

In fragments.

If You’re Facing the Same Friction

If terminal customization feels like a chore → TermiCool

If your PDF exports destroy what you built → TreePress

If you keep rebuilding Claude Code setup from scratch → CCL

I built these because the pain was real.

Maybe one of them saves you a few hours too.

Your Turn

What repetitive frustration have you been tolerating for too long?

And which one of these feels the most painful to you?

Would love to hear it ↓

Building an Authentication Starter: Lessons from Integrating Next.js, PostgreSQL, Prisma, and NextAuth

Berkay Sonel — Sat, 09 May 2026 11:36:14 +0000

Building an Authentication Starter: Lessons from Integrating Next.js, PostgreSQL, Prisma, and NextAuth

When starting a new web project, setting up user authentication can often feel like a significant initial friction. There are many components involved: managing user data, securing routes, handling different login methods, and keeping everything type-safe. My goal was to create a solid starting point for future projects, something that handles these complexities without requiring extensive setup each time. This led me to develop a Next.js authentication starter app, and I'd like to share some insights from the process.

The Foundation: Why These Technologies?

The project is built on a few core technologies, chosen for their individual strengths and how well they work together. These technologies also promising and future proof.

Next.js

I chose Next.js 14 as the application framework. Its App Router structure makes route definition and data fetching much clearer, especially for server-side rendered applications. It offers a modern approach that simplifies many common web development tasks.

PostgreSQL & Prisma

For data management, I implemented for PostgreSQL and Prisma. PostgreSQL is a widely used relational database, known for its stability. Prisma, as an ORM, significantly simplifies database interactions. It provides a type-safe way to define models and perform queries, which was a huge win for developer experience and reducing potential bugs. Defining my database schema in prisma/schema.prisma and using Prisma migrations felt a natural fit for managing changes.

NextAuth.js

NextAuth.js handles the core authentication logic. It abstracts away much of the complexity of session management, social logins (like Google and GitHub), and callback handling. Configuring it in auth.config.ts allowed me to define providers and custom callbacks easily.

Additional Tools

Resend: For sending emails related to verification and password resets. This was chosen for its developer-friendly API.
Tailwind CSS & ShadCN: To get a user interface up and running quickly. Tailwind CSS helps with rapid styling, and ShadCN provides a collection of accessible components built on top of it.
Zod: For form validation. Defining schemas in schemas/ made sure my data inputs were always correctly formatted and type-safe, preventing many common form-related issues.
bcryptjs: For password encryption, a crucial security measure.

Key Features I Focused On

This starter app includes several features designed to cover common authentication needs:

User Forms: Login, verification, update password, reset password and registration pages, supporting both email/password and social logins (Google, GitHub).
Protected Routes: Implementing middleware.ts to check user sessions before allowing access to specific parts of the application, like /settings. The user should add his/her application pages to here.
Email Verification & Password Reset: Generating secure tokens and using Resend to send emails for these critical flows.
Data Handling: A clear separation between actions/ for database mutations and data/ for read operations.

How the Project is Organized

Understanding the project's layout was important for building it and will be for anyone extending it.

app/: Contains all route definitions, including public routes like / and /auth/login, and protected routes like /(protected)/settings. App router.
actions/: Where server actions live, connecting to the database for operations like creating a new user or updating a profile.
data/: Functions for fetching data from the database, typically read-only.
components/: My reusable UI elements, keeping the interface consistent.
lib/: General utilities and helpers.
prisma/: Holds the Prisma schema and generated client for database models and migrations.
schemas/: All Zod validation schemas, ensuring data integrity.
middleware.ts: Handles route protection and authentication checks.
auth.config.ts: NextAuth configuration details, including providers and callbacks.

Insights and Lessons Learned

One of the main takeaways from putting this together was the power of explicit data validation with Zod. It really helped to catch errors early and provided clear feedback for form inputs. Separating concerns between actions/ and data/ also made the server-side logic much easier to reason about and maintain as the project grew. User can use tanstack query or useSwr for data fetching, starter pack enables every possible way that user can go.

Thinking about alternatives, I considered different ORMs like neon, but Prisma's type-safety with TypeScript was a strong argument for its use and also very easy to use, I found that Neon is another powerful alternative but for a starter kit it was too much like raw SQL. For email sending, there are many options, but Resend's API worked well for integrating token generation. These parts very easy to change and use alternative.

Concluding Thoughts

This Next.js authentication starter project is designed to offer a solid starting point for applications needing user authentication. It brings together well-regarded tools to handle many common challenges. If you're looking to kickstart a project with Next.js 14 and need a reliable authentication setup, feel free to explore it. I'm always open to hearing about different approaches or improvements!

Repo:

Next.js Auth Starter

Attractor Engineering: Seeing Software Development as Field Dynamics

Hiroyuki Nakahata — Sat, 09 May 2026 11:25:16 +0000

TL;DR

A codebase can be read as a field that attracts future changes, and a pull request can be read as a force applied to that field.

A good field makes good changes easier to make. A bad field repeatedly makes bad shortcuts look natural. In an era where AI can produce PRs quickly, this attraction becomes stronger.

I call the practice of designing where future changes are pulled Attractor Engineering.

CI/CD, tests, reviews, and harnesses can be read as dissipative systems: they remove unwanted force and shape the trajectory.

ArchSig, or Architecture Signature, is a tool for observing that trajectory along multiple axes.

The first half of this article is written for practitioners: it explains the intuition in terms of codebases, PRs, review, CI, and AI-assisted development. The second half is more mathematical: it connects the same intuition to AAT, Architecture Signature, Lean formalization, and finite counterexamples.

The First Discovery

The starting point was a simple thought experiment.

What if we look at software architecture not only as a set of directories, design rules, or conventions, but as an algebraic structure?

From that point of view, everyday changes such as feature additions, refactorings, splits, migrations, repairs, protections, deletions, and integrations become operations acting on the structure we call architecture.

current codebase
  + feature addition
  + refactoring
  + review fix
  + migration
  + repair
  -> next codebase

If we take one more step, we can ask: if these operations are not applied once, but repeated dozens or hundreds of times, can the whole development process be read as a kind of dynamics?

Each individual PR is small.

But after enough PRs, the codebase gradually moves in some direction.

When a good structure already exists, the next change tends to fit into a good place.

When a bad structure exists, a locally natural change tends to take the same bad shortcut again.

Can we treat "where changes tend to go" as something we design?

I decided to call this way of thinking Attractor Engineering.

A Codebase Is a Field, and a PR Is a Force

The central interpretation is this:

codebase = a field that attracts changes
PR       = a force applied to that field
ArchSig  = an observer for the movement

A codebase is not a neutral space that passively receives future changes.

Existing names, types, responsibility boundaries, tests, directory structure, previous implementation examples, and review culture all shape which next change feels natural.

A PR is a force applied to that field. Each one may be small, but repeated PRs create a trajectory of change.

current codebase
  -> a PR is applied
  -> an architectural change is observed
  -> a trajectory of change emerges
  -> this becomes the next codebase

The important point is that a PR changes the codebase, and the changed codebase then changes what the next PR is likely to look like.

People and Systems Create the Field

This field is not created only by engineers.

Product managers, product owners, engineers, reviewers, AI agents, CI, tests, design documents, coding standards, and existing examples all participate in it.

Everyone and everything involved in development affects which changes become likely next.

Participant / mechanism	Effect on the field
Product manager	Decides which values and demands are repeatedly injected into the system.
Product owner	Shapes PRs through requirement granularity, priorities, and acceptance criteria.
Engineer / architect	Creates paths for change through boundaries, abstractions, standard patterns, and reference implementations.
Reviewer	Pushes back bad force and redirects it toward better directions.
CI / tests / types	Rejects, weakens, and narrows inappropriate force.
AI agent	Reads the existing field and quickly proposes changes.

The way requirements are sliced, prioritized, scheduled, and accepted changes how later PRs are produced. Even people who do not write code apply indirect force to the field of the codebase.

This becomes especially important in AI-assisted development. Vague requirements can quickly become vague PRs. If boundaries and non-goals are clear, an AI system is more likely to produce useful changes within those boundaries.

What Changes in AI-Assisted Development

The essence of AI-assisted development is not simply that code can be written faster.

The more important change is that the distribution of selected change operations changes.

An AI system reads existing code, neighboring files, names, types, tests, previous implementation examples, READMEs, and design documents, and then generates the next proposed change.

In other words, the whole codebase becomes input context for the AI.

the codebase becomes input context for AI
  -> AI proposes a change
  -> the proposal becomes a PR
  -> review / CI / merge process handles it
  -> the codebase is updated
  -> the next input context changes

If a good reference implementation is nearby, the AI is likely to imitate it.

If a bad shortcut already exists, the AI is also likely to treat it as a natural option.

In this sense, AI rapidly reproduces the local style already present in the field. That is why, in the AI era, what matters is not only the capability of an individual AI agent. The design of the field in which the AI participates matters just as much.

What Is an Attractor?

When a codebase contains a huge common module, an overly convenient helper, or an ambiguous service, changes tend to be pulled there.

Conversely, when good responsibility boundaries and clear implementation examples exist, the next change tends to follow them.

This destination toward which changes are pulled is what I call an attractor. When something moves repeatedly, it often tends to approach certain places or states.

The surrounding region from which things are likely to fall into that attractor is what I call a basin.

Technical debt can be read as a bad basin.

Once a codebase falls into it, locally natural changes keep adding to the same place, and the cost of refactoring out of it grows higher and higher.

The important point is that attractors can be good or bad.

A good attractor pulls in good changes.

A bad attractor makes bad shortcuts get selected again and again.

What Is Attractor Engineering?

Attractor Engineering is the idea that we should deliberately design these attractors.

Its target is not just the codebase.

It includes the whole development organization: product managers, product owners, engineers, reviewers, AI agents, CI/CD, tests, design documents, and coding standards.

The goal is not only to block bad changes from the outside. The goal is to create a field where good changes are naturally easier to select.

Part of Attractor Engineering	What it shapes	Examples
Create the field	Which changes feel natural to propose.	Requirements, priorities, design boundaries, types, APIs, examples, templates.
Dissipate bad force	Which proposed changes are rejected, weakened, or redirected.	Harnesses, CI, tests, reviews, PR granularity.
Observe the trajectory	How architectural movement becomes visible over time.	ArchSig, architecture features, drift reports.

Attractor Engineering is an integrated design theory for the era of AI-assisted development. It treats the entire development organization as part of the system.

Harness Engineering as a Dissipative System

We cannot simply take changes produced by AI and put them directly into the codebase.

Harnesses, CI, tests, type checking, static analysis, and review divide proposed changes into "accept", "fix and check again", and "do not merge".

In Attractor Engineering, this behavior can be read as dissipation.

Dissipation is the mechanism that removes unwanted components of the force entering the field.

If dissipation is too weak, the fast change force produced by AI enters the codebase directly. If it is too strong, nothing moves. A good harness weakens the force that increases debt while preserving the force that moves the product forward.

In this view, CI/CD is not merely a checklist. It is more like brakes, rails, signals, and safety equipment that convert fast PR generation into safe productivity.

What matters in AI-assisted development is not only making the engine stronger.

It is also preparing the field and the dissipative system that can receive a stronger engine.

What ArchSig Observes

To design the field, we need to observe what is happening.

That is the role of ArchSig.

ArchSig is short for Architecture Signature.

In my repository, I use it to mean an observation framework for reading changes in a codebase or PR along multiple axes. Dependencies, boundaries, abstractions, runtime exposure, semantic drift, and test observability are not collapsed into a single score. They are treated as multiple features.

ArchSig is an observer for seeing which direction a PR moves the architecture.

For example, we may observe axes like these:

Axis	What we want to observe
Static dependencies	Dependency direction and violations of forbidden dependencies.
Boundary rules	Connections that cross boundaries or bypass rules.
Abstraction leakage	Concrete dependencies that jump over abstractions.
Semantic drift	Whether responsibilities or meanings have shifted away from what was intended.
Test observability	Whether the change can be observed through tests.
Per-PR change	How each axis moves in a single PR.

The important point is that we do not compress good and bad into one score.

What we want to know is which axes got worse, which axes improved, and what kind of force each change applies.

PR
  -> observe change with ArchSig
  -> observe the trajectory of change
  -> see whether it is moving toward a good or bad region

ArchSig becomes an observer for the AI PR era.

Are AI-generated changes moving toward good attractors?

Are they falling into a pool of technical debt?

Is the harness dissipating enough bad force?

ArchSig gives us shared language for discussing those questions.

PRs Become More Important, Not Less

When AI reduces the cost of generating code, it may look as if PRs become less important.

From a dynamical systems viewpoint, the opposite is true.

A PR is not just a work unit.

A PR has the following roles:

It cuts continuous change into observable units.
It lets us separate the directions in which a change acts.
It embeds the dissipative process of review, CI, and approval.
It creates a boundary for rollback and reversibility.
It creates a unit for decision-making and discussion.

What AI lowers is mainly the cost of producing a PR.

But the value of PRs as units of observation, decomposition, dissipation, reversibility, and decision-making increases. In the AI era, PRs do not become unnecessary. They become more important as units for observing and controlling architectural movement.

Future Development Organizations

In future development organizations, the central problem will not be only how fast we can write code. It will be how to design a field that can safely receive that speed.

A fast train cannot run safely just because it has a powerful motor.

It needs rails, brakes, signals, safety equipment, and operations control.

Software development is similar. AI is a powerful motor, but by itself it can create semantic drift, responsibility drift, degradation of design properties we wanted to preserve, merge confusion, and flow toward technical debt.

What we need is a field with properties like these:

Small and observable PRs.
Fast feedback.
Reliable CI.
A useful type system.
Architecture tests.
Carefully selected reference implementations.
Isolation of legacy code.
Clear demands, requirements, and design boundaries.
Human-designed boundaries for value and acceptance criteria.

The safest AI coding environment is not the one with the strongest external harness. It is the one where good changes are natural, easy to imitate, observable, and less likely to fall into bad shortcuts.

Summary So Far

The success or failure of AI-assisted development is not determined only by how fast AI can write code.

The direction of the next PR changes depending on the field created by the codebase, requirements, design boundaries, reference implementations, review, CI/CD, and ArchSig.

A good field attracts good changes. A bad field repeatedly makes bad changes look natural. That is why architecture design in the AI era becomes the design of where future changes are attracted.

So far, this has been Attractor Engineering in practical engineering language. In the second half, I translate the same intuition into the language of AAT, Algebraic Architecture Theory, and dynamical systems.

From Here, in Mathematical Language

The rest of this article uses more mathematical formulation. If you only want the practical view first, it is fine to skip to the conclusion.

Around AI development, there are many heuristics: "this prompt worked", "this workflow made us faster", and so on. These heuristics are valuable. But by themselves, they make it hard to separate why something worked, how far it generalizes, and under what conditions it breaks.

So I decompose the flow: a change is selected, becomes a PR, passes review / CI, is merged, and then the updated codebase changes the distribution of future changes. By separating state, operation, observation, invariant, obstruction witness, and proof obligation, we can turn heuristics into something easier to test.

A Short Introduction to AAT

The background theory for this discussion is AAT, or Algebraic Architecture Theory. Here I introduce only the minimal vocabulary needed for the rest of the article.

The Lean snippets below are excerpts from implemented APIs, adjusted for readability. Namespaces, imports, and some proof bodies are omitted.

AAT treats software development not merely as a sequence of code changes, but as a theory of architectural extension, decomposition, repair, and composition.

Its central proposition does not appear in Lean as one large equation. It appears as packages that combine operations and proof obligations.

structure OperationProofObligation (State : Type u) (Witness : Type v) where
  kind : ArchitectureOperationKind
  obligation : ProofObligation State Witness
  precondition : Prop
  nonConclusion : Prop

Operations are first classified as an operation catalog on the Lean side.

inductive ArchitectureOperationKind where
  | compose
  | refine
  | abstract
  | replace
  | split
  | merge
  | isolate
  | protect
  | migrate
  | reverse
  | contract
  | repair
  | synthesize
  deriving DecidableEq, Repr

The important point is that names such as split or repair prove nothing by themselves. An operation kind is a classification for theorem packages. Claims about preservation, improvement, or repair must be stated separately as proof obligations.

From this viewpoint, a design review is not only the question "is this design good or bad?"

- Is the existing structure embedded after extension?
- Can the new feature be split out from the existing structure?
- Do interactions pass through declared interfaces?
- Which invariants are preserved, and which invariants were broken?
- If a split is not possible, which obstruction witness blocks it?

The smallest object in AAT is ArchitectureCore.

structure ArchitectureCore (C : Type u) (A : Type v)
    (StaticObs : Type w) (SemanticExpr : Type q)
    (SemanticObs : Type r) where
  flatness :
    ArchitectureFlatnessModel C A StaticObs SemanticExpr SemanticObs
  staticUniverse : ComponentUniverse flatness.static
  componentDecidableEq : DecidableEq C
  staticEdgeDecidable : DecidableRel flatness.static.edge
  runtimeEdgeDecidable : DecidableRel flatness.runtime.edge
  boundaryPolicyDecidable : DecidableRel flatness.boundaryAllowed
  abstractionPolicyDecidable : DecidableRel flatness.abstractionAllowed
  runtimeRole : C -> C -> RuntimeDependencyRole
  semanticRequiredDecidable :
    ∀ d : RequiredDiagram SemanticExpr,
      Decidable (flatness.requiredSemantic d)

Here it is important that ArchitectureCore is not the whole real-world codebase itself. It is a finite or bounded object extracted from code, specifications, reviews, and operational observations so that the theory can handle it.

Feature addition is read as an operation that extends an existing architecture into a larger one while preserving the existing architecture.

ExistingCore X
  -> ExtendedArchitecture X'
  -> FeatureView F

In a good feature extension, the existing core is preserved inside the extension, the feature view can be extracted in an explainable way, and interactions from the feature to the core pass through declared interfaces. Conversely, hidden dependencies, boundary policy violations, abstraction leakage, runtime exposure, and semantic mismatch are treated not as impressions, but as ObstructionWitness values.

To count, remove, preserve, or explicitly decline to conclude about these obstructions, AAT makes ProofObligation and Certificate explicit.

structure ProofObligation (State : Type u) (Witness : Type v) where
  formalUniverse : Prop
  requiredLaws : Prop
  invariantFamily : State -> Prop
  witnessUniverse : Witness -> Prop
  coverageAssumptions : Prop
  exactnessAssumptions : Prop
  operationPreconditions : Prop
  conclusion : Prop
  nonConclusions : Prop

An obligation is not discharged merely because it exists. It is discharged only when the visible assumptions imply the conclusion.

def AssumptionsHold (P : ProofObligation State Witness) : Prop :=
  P.formalUniverse ∧
  P.requiredLaws ∧
  P.coverageAssumptions ∧
  P.exactnessAssumptions ∧
  P.operationPreconditions

def Discharged (P : ProofObligation State Witness) : Prop :=
  AssumptionsHold P -> P.conclusion

The same is true for certificates. For example, in repair synthesis, if we say "there is no solution", solver failure alone is not enough. Only when a valid certificate exists do we use soundness to conclude that no satisfying architecture exists.

structure NoSolutionCertificate
    {State : Type u} {Constraint : Type c} (Certificate : Type v)
    (C : SynthesisConstraintSystem State Constraint)
    (cert : Certificate) where
  valid : Prop
  sound : valid -> NoArchitectureSatisfies C
  coverageAssumptions : Prop
  exactnessAssumptions : Prop
  nonConclusions : Prop

theorem sound_of_valid
    (pkg : NoSolutionCertificate Certificate C cert)
    (hValid : ValidNoSolutionCertificate pkg) :
    NoArchitectureSatisfies C

nonConclusions is not decoration. Even if a static split is proved, runtime flatness or semantic flatness does not automatically follow. Even if no obstruction is found in one observation universe, that does not imply there is no obstruction in every universe. Making this boundary explicit is necessary if we want to treat the theory as testable rather than as a collection of engineering anecdotes.

ArchitectureSignature is also not intended to collapse architecture quality into a single score. It is a multi-axis diagnosis for reading multiple invariant and obstruction families axis by axis.

structure ArchitectureSignatureV1 where
  core : ArchitectureSignatureV1Core
  weightedSccRisk : Option Nat
  projectionSoundnessViolation : Option Nat
  lspViolationCount : Option Nat
  nilpotencyIndex : Option Nat
  runtimePropagation : Option Nat
  relationComplexity : Option Nat
  empiricalChangeCost : Option Nat
  deriving DecidableEq, Repr

Some axes are Option Nat because an unmeasured value must not be treated as zero. none does not mean "no problem". It means "not measured in this universe / extractor / bridge".

theorem not_axisAvailableAndZero_of_axisValue_none
    {sig : ArchitectureSignatureV1} {axis : ArchitectureSignatureV1Axis}
    (hNone : axisValue sig axis = none) :
    ¬ axisAvailableAndZero sig axis

From this perspective, a signature is not a convenient bag of metrics. It is a multi-axis invariant relative to a law universe. For selected required law axes, there are also bridge theorems connecting lawfulness and zero signature axes.

theorem architectureLawful_iff_requiredSignatureAxesZero
    {C : Type u} {A : Type v} {Obs : Type w}
    (X : ArchitectureLawModel C A Obs)
    [DecidableEq C] [DecidableEq A] [DecidableEq Obs]
    [DecidableRel X.G.edge] [DecidableRel X.GA.edge]
    [DecidableRel X.boundaryAllowed]
    [DecidableRel X.abstractionAllowed] :
    ArchitectureLawful X ↔
      RequiredSignatureAxesZero (ArchitectureLawModel.signatureOf X)

AAT does not treat every claim at the same level. It separates definitions, proved theorem packages, bounded bridge theorems, tooling-side evidence, and empirical hypotheses. It also records which universe, observation, coverage, and exactness assumptions each claim is relative to.

The dynamics part below follows the same discipline. The important point is that AAT is not using mathematical vocabulary for atmosphere. It is trying to make the assumptions, conclusions, and non-conclusions part of the type-level structure.

So far, AAT gives us vocabulary for a single architectural state and operations acting on it.

But in AI-assisted development, the central issue is not only a single operation. Requirements, existing code, review, CI, and AI agents change which operation is likely to be selected next, and this selection is repeated many times.

So we need to view AAT operations not only as one-time proof targets, but also as transformations repeatedly selected over time. This is where a chaos-game-like reading enters.

Formalizing Attractor Dynamics

From here, I use AAT vocabulary to rewrite "field", "force", "dissipation", and "observation" in a more mathematical form.

This is not merely a metaphor that says "AI development is kind of like a chaos game". It is an attempt to place PR force, operation support, trajectory, and basin candidates on top of the AAT vocabulary of state, operation, invariant, obstruction, proof obligation, certificate, and signature.

At this stage, I should be careful: this is not a finished theorem of real-world software development. It is a way to organize phenomena that practitioners can feel, in a structure that may eventually support measurement and verification.

The minimal loop of the dynamics can be read as follows:

architecture field
  -> operation distribution
  -> accepted / rejected transitions
  -> signature trajectory
  -> updated architecture field

The position is that architecture quality is not only a property of a snapshot. It is also a property of the future operation distribution and the signature trajectory.

1. State, Operation, Observation

Let the architectural state be X_t.

Feature addition, repair, split, protection, migration, and refactoring are operations acting on that state.

X_{t+1} = op_t(X_t)

The operation op_t is not selected uniformly at random.

The current codebase, requirements, prompt, review policy, CI, design boundaries, and organizational judgment all change which operations are likely to be selected.

op_t ~ P(operation | X_t, control_t)

This probability expression is notation for the practical reading. The formal core of AAT is not a probability distribution. It is finite or bounded operation support, bounded scripts, accepted transition predicates, and explicit preservation assumptions.

In Lean, for example, operation support is represented not as a probability distribution, but as a finite list of candidate operations for each state.

structure FiniteOperationKernel
    (State : Type u) (OperationId : Type w) where
  support : State -> List OperationId
  coverageAssumptions : Prop
  weightSourceBoundary : Prop
  normalizationBoundary : Prop
  nonConclusions : Prop

Weights, normalization, and completeness of AI-generated proposals are not mixed into the theorem here. Boundaries such as weightSourceBoundary and normalizationBoundary record what is outside the formal claim, and the probabilistic reading remains outside that core.

Likewise, repeated operation sequences are first treated as bounded scripts.

structure BoundedOperationScript (OperationId : Type w) where
  operations : List OperationId
  operationFamily : OperationId -> Prop
  operationsInFamily :
    ∀ op, op ∈ operations -> operationFamily op
  coverageAssumptions : Prop
  nonConclusions : Prop

This boundary helps avoid confusing probabilistic interpretation with preservation claims over finite support.

Instead of observing the entire state directly, we map it into signature space through an observation function Obs.

sigma_t = Obs(X_t)

This sigma_t is the Architecture Signature.

It contains multi-axis observations such as dependency direction, boundaries, abstraction, runtime exposure, and semantic mismatch.

In Lean, even the observation itself is packaged. The package contains not only the observation function, but also coverage and non-conclusion boundaries.

structure SignatureObservation (State : Type u) (Sig : Type v) where
  observe : State -> Sig
  coverageAssumptions : Prop
  nonConclusions : Prop

When architectural evolution is mapped into observation space, we get a signature trajectory.

def SignatureTrajectory (O : SignatureObservation State Sig) :
    {X Y : State} -> ArchitectureEvolution State X Y -> List Sig
  | X, _, ArchitecturePath.nil _ => [O.observe X]
  | X, _, ArchitecturePath.cons _step rest =>
      O.observe X :: SignatureTrajectory O rest

A change moves the signature.

Delta_t = sigma_{t+1} - sigma_t

This Delta_t can be read as the force applied by the PR or operation.

However, not every axis admits simple subtraction. For numeric axes, we may read it as a signed delta. For other axes, we read it as a before / after comparison, the appearance of a witness, or a change in state classification.

2. PR Force Model

With this structure, a PR becomes more than a diff.

A PR can be read as a force applied to the codebase in the selected Architecture Signature space.

PRForce(PR) = sigma(after(PR)) - sigma(before(PR))

The word force here does not mean physical force. It means an observed change in signature, relative to which axes are observed and which differences are defined.

Delta sequences, like trajectories, are relative to finite paths in Lean.

def SignatureDeltaSequence
    (O : SignatureObservation State Sig) (D : SignatureDelta Sig Delta) :
    {X Y : State} -> ArchitectureEvolution State X Y -> List Delta
  | _, _, ArchitecturePath.nil _ => []
  | X, _, ArchitecturePath.cons (Y := Y) _step rest =>
      D.between (O.observe X) (O.observe Y) ::
        SignatureDeltaSequence O D rest

For selected additive deltas, the sum of step deltas agrees with the endpoint delta. This is proved as a theorem.

theorem netSignatureDelta_telescopes [Zero Delta] [Add Delta]
    (O : SignatureObservation State Sig) (D : SignatureDelta Sig Delta)
    (law : AdditiveSignatureDeltaLaw D) :
    {X Y : State} -> (plan : ArchitectureEvolution State X Y) ->
      NetSignatureDelta (SignatureDeltaSequence O D plan) =
        EndpointSignatureDelta O D plan

But this theorem is finite path calculus under the assumption that the selected delta satisfies an additive law. It does not claim that unobserved axes, incident risk, review quality, or actual PR outcomes can all be added this way.

The force has multiple components.

Force component	Meaning
Feature force	The force that moves product functionality forward.
Repair force	The force that repairs existing breakage.
Coupling force	The force that increases or decreases coupling.
Boundary force	The force that preserves or violates boundaries.
Type force	The force that adds type information or creates type holes.
Test force	The force that increases or decreases observability through tests.
Debt force	The force that pushes the system toward a bad basin.
Refactor force	The force that helps it escape a bad basin.

A good PR has not only feature force, but also stabilizing force.

v_PR = v_feature + v_stabilize

A risky PR moves the feature forward locally while quietly adding small debt force.

v_PR = v_feature + v_debt

In AI-generated PRs, the especially important case is one where tests pass and the specification is satisfied, but small v_debt, v_coupling, v_type_hole, or v_entropy accumulates repeatedly. It may be hard to see in a single PR. But as a trajectory, the system is moving toward a bad basin. I call this the Local Correctness Trap.

3. Three Classes of Force

The earlier discussion about product managers, product owners, review, and CI/CD becomes clearer if we separate force by observability.

Force can be divided into three classes.

Force class	Meaning	Main evidence
ObservedForce	Before / after signature delta of PRs that were actually merged.	PRs, ArchSig reports, drift ledger.
LatentForce	Invisible force by which requirements, design, prompts, and local code style shape which PRs are proposed.	Requirements, prompts, proposal logs, case studies.
DissipatedForce	Raw force that was rejected, corrected, or weakened by review / CI / types / policy.	CI failures, requested changes in review, rejected proposals.

This classification makes AI-assisted development more concrete.

If we look only at merged PRs, we see only ObservedForce.

But in an era where AI can generate many proposals, the force that was not merged also matters. Force removed by review, rejected by CI, or reshaped before merge matters.

To understand how well a dissipative system is working, we need DissipatedForce.

To understand what kind of PR distribution is created by upstream requirements or prompts, we need LatentForce.

In Lean, the separation between accepted and rejected changes appears as a damping / control schema.

structure DampingControlSchema (State : Type u) (Sig : Type v) where
  observation : SignatureObservation State Sig
  invariant : SafeRegion Sig
  accepted :
    {X Y : State} -> ArchitectureTransition State X Y -> Prop
  rejected :
    {X Y : State} -> ArchitectureTransition State X Y -> Prop
  acceptedPreservesInvariant :
    ∀ {X Y : State} (t : ArchitectureTransition State X Y),
      accepted t -> StepPreservesSafeRegion observation invariant t
  coverageAssumptions : Prop
  nonConclusions : Prop

What this proves is limited: transitions classified as accepted preserve the explicitly stated invariant. The existence of rejected changes does not prove that the whole future of the codebase is safe.

On top of this schema, it is proved that accepted finite evolutions create trajectories inside the selected invariant.

theorem acceptedEvolution_preserves_selectedInvariant
    (control : DampingControlSchema State Sig) :
    {X Y : State} -> (plan : ArchitectureEvolution State X Y) ->
      StateInSafeRegion control.observation control.invariant X ->
      control.AcceptedEvolution plan ->
        SignatureTrajectoryInSafeRegion
          control.invariant (SignatureTrajectory control.observation plan)

4. A Chaos-Game-Like Correspondence

This is where the chaos-game-like reading appears.

The similarity is that we have multiple transformations, one of them is selected at each step, and a state trajectory is produced.

The difference is that, in software development, neither the set of transformations nor their likelihood is fixed. Requirements, review, CI, design boundaries, existing examples, and AI agent behavior all affect which operation is likely to be selected next.

So the goal is not to claim that software development literally is the classical chaos game. The goal is to use AAT vocabulary to handle the structure where multiple operations are repeatedly selected and the resulting trajectory tends to move toward certain regions.

The correspondence is:

Chaos-game side	AAT / development side
State `X_t`	Architecture state / codebase field.
Transformation `f_i`	Architecture operation / PR / patch.
Transformation selection	Operation selection by developer / AI / requirement / review.
Trajectory	Architecture Signature trajectory.
Attractor	Signature region where the system tends to stay.
Basin	Initial or surrounding states likely to fall into that attractor.
Control input	Prompt, review policy, CI, type checker, architecture rule.

As a formula:

X_{t+1} = f_{i_t}(X_t)
i_t ~ P(. | X_t, control_t)
Y_t = sigma(X_t)

The important point is not to assert probability or attractors as strong theorems too early.

What we should handle in practice is first an attractor candidate or basin candidate relative to a finite observation window, bounded horizon, selected signature axes, and selected operation support.

finite observed trajectory
  + selected signature region
  + bounded operation support
  -> attractor / basin candidate

This is not an escape into weak claims. It is a boundary that makes measurement and falsification possible.

5. Support Shaping

The mathematical core of Attractor Engineering is support shaping.

This is not just about "blocking bad PRs". It is about changing the set of operations that can naturally be selected next, and changing how likely they are to be selected.

In short, Attractor Engineering is a theory of designing the geometry of the operation distribution.

def Supports
    (kernel : FiniteOperationKernel State OperationId)
    (X : State) (op : OperationId) : Prop :=
  op ∈ kernel.support X

For the current architecture state X, the set of operations that can naturally be selected is called operation support.

Good design changes this support.

def SupportOperationsPreserveSafeRegion
    (kernel : FiniteOperationKernel State OperationId)
    (sem : OperationTransitionSemantics State OperationId)
    (O : SignatureObservation State Sig) (R : SafeRegion Sig) : Prop :=
  ∀ {X : State} (op : OperationId),
    kernel.Supports X op -> sem.OperationPreservesSafeRegion O R op

The strong form of support shaping says: operations that remain in support preserve the selected safe region. In practical terms, we reduce bad operations, increase good operations, make correct paths easier to choose, and make dangerous shortcuts less convenient.

This idea is packaged on the Attractor Engineering side as follows:

structure AttractorEngineeringSupportPackage
    (State : Type u) (Sig : Type v) (OperationId : Type w) where
  observation : SignatureObservation State Sig
  kernel : FiniteOperationKernel State OperationId
  semantics : OperationTransitionSemantics State OperationId
  targetRegion : SafeRegion Sig
  supportPreserves :
    kernel.SupportOperationsPreserveSafeRegion semantics observation targetRegion
  coverageAssumptions : Prop
  measurementBoundary : Prop
  nonConclusions : Prop

With this package, if a bounded script uses only operations from finite support, and the starting point is in the target region, then the observed trajectory remains in the target region. This is stated as a theorem.

theorem supportPackage_preserves_targetTrajectory
    (package : AttractorEngineeringSupportPackage State Sig OperationId)
    (script : BoundedOperationScript OperationId)
    {X Y : State} (plan : ArchitectureEvolution State X Y)
    (hStart :
      StateInSafeRegion package.observation package.targetRegion X)
    (hRealizes : script.RealizesEvolution package.semantics plan)
    (hSupport :
      package.kernel.ScriptUsesSupport script.operations plan) :
    SignatureTrajectoryInSafeRegion package.targetRegion
      (package.TargetTrajectory plan)

For example, good APIs, good examples, clear ownership, narrow modules, and domain states represented in types increase the local discoverability of good operations.

Conversely, a huge common module, implicit global context, ambiguous services, and overly convenient helpers increase the local convenience of bad operations.

From this viewpoint, refactoring is not only cleaning up the current structure. It is also a basin-reshaping operation that changes the future operation distribution.

In the measurement layer, one tooling-side metric candidate to watch here is SupportRiskMass.

SupportRiskMass(C) =
  sum over op in support(C) of weight(op) * risk(op, C)

Here again, it is important not to reduce risk to a simple 0 / 1.

In AAT terms, we should distinguish at least:

safe-preserving proved
safe-preserving measured
safe-preserving estimated
unsafe witness measured
unmeasured
unavailable
private
notComparable
outOfScope

Unmeasured must not be read as zero. This is a central principle in both ArchSig and AAT.

6. The Same Signature Does Not Imply the Same Future

An important point is that two states can have the same current Architecture Signature but different future operation distributions.

For example, two modules might show the same number of dependency violations, the same test coverage, and the same complexity. But one may have a good canonical example nearby, while the other may contain many bad shortcuts.

Even if the current observation values are the same, future PRs may be attracted in different directions.

Obs(X) = Obs(Y)
  does not imply
OperationSupport(X) = OperationSupport(Y)

This is why architecture quality should not be judged by snapshot metrics alone. The current value can be the same while the future force field is different. Attractor Engineering treats this future force field as a design object.

7. Accepted Preservation and Support Preservation Are Different

There is another important separation.

Suppose review and CI ensure that merged PRs preserve a safe region.

Even then, unsafe operations may still remain inside operation support.

This separation is not just a warning. It appears on the Lean side as a finite counterexample. Accepted-step invariant preservation can hold, and an accepted safe step can exist, while operations that do not preserve the safe region remain in support.

theorem acceptedPreservation_not_supportPreservation_counterexample :
    (∃ (t : ArchitectureTransition ExampleState safeState safeState),
      control.AcceptedStep t ∧
        StepPreservesSafeRegion control.observation control.invariant t) ∧
    (∀ {X Y : ExampleState} (t : ArchitectureTransition ExampleState X Y),
      control.AcceptedStep t ->
        StepPreservesSafeRegion control.observation control.invariant t) ∧
    (∃ X op,
      kernel.Supports X op ∧
        ¬ semantics.OperationPreservesSafeRegion control.observation
          control.invariant op)

This is the difference between guardrails and attractor engineering.

Strong guardrails may stop bad PRs.

But a field where bad PRs are produced in large numbers every time is still not a good field.

A good field is one where bad operations are less likely to appear in the first place, and good operations are natural, easy to imitate, observable, and low-friction.

8. PRs Are Non-Commutative

PRs are generally non-commutative.

PR_2 o PR_1 != PR_1 o PR_2

Of course, this only makes sense when both orders can be applied. Even then, the same two PRs can produce different final signatures depending on merge order.

This matters in an era where AI agents can generate multiple PRs in parallel.

Even when individual PRs are locally correct, their order can change boundaries, types, tests, and semantic alignment.

I call this merge order sensitivity.

MergeOrderSensitivity(a, b, X) =
  distance(
    sigma(b(a(X))),
    sigma(a(b(X)))
  )

This is not merely a merge conflict issue. It is the non-commutativity of operation algebra branching the signature trajectory. We will need this viewpoint when evaluating teams of AI agents as well.

9. Observe the Shape of the Trajectory

Architecture Signature should be read not only as a current value, but also as a trajectory.

Even if the endpoint is safe, the path may have passed through a bad region.

Even if net delta is zero, there may have been large churn inside the path.

endpoint safe
  does not imply path safe

net force zero
  does not imply no excursion

This is also proved in Lean as a small finite counterexample. In a trajectory such as 0 -> 2 -> 0, both endpoints are the same safe state. The endpoint delta and net delta can both appear to be zero, while the path passed through an unsafe region.

theorem netSignatureDelta_eq_zero :
    NetSignatureDelta (SignatureDeltaSequence observation signedNatDelta
      excursionPlan) = 0

theorem endpointSafe_and_zeroDelta_but_not_pathSafe :
    EndpointSignatureDelta observation signedNatDelta excursionPlan = 0 ∧
      StateInSafeRegion observation safeRegion 0 ∧
      StateInSafeRegion observation safeRegion 0 ∧
      ¬ SignatureTrajectoryInSafeRegion safeRegion
          (SignatureTrajectory observation excursionPlan)

Trajectories have shapes.

Trajectory type	Meaning
Stable Orbit	The system returns to a safe region after small changes.
Drift	The system slowly shifts toward a bad region.
Spiral Debt	It appears to return, but over the long run moves closer to a bad basin.
Sudden Phase Shift	A signature changes sharply after a particular PR.
Oscillation	Feature additions and refactorings alternate between good and bad.
Basin Capture	After some point, the system gets captured by a bad structure.

What ArchSig really wants to observe is this trajectory.

Not just the evaluation of one PR, but the resulting motion produced by a group of PRs.

10. Expanding Observation Can Suddenly Reveal Badness

With coarse observation, a codebase may look safe.

But if we add more observation axes, a hidden obstruction may suddenly appear as nonzero.

coarse observation:
  safe

refined observation:
  hidden obstruction appears

We can call this an observability expansion shock.

The important point is that this does not necessarily mean the architecture got worse. It may simply mean that an axis that used to be invisible has become visible.

That is why ArchSig must distinguish unmeasured from zero. When something that was not measured becomes visible, we must separate "the architecture got worse" from "the observation became better".

About the Lean Formalization

The structure above is not built only from metaphor. Some of the core vocabulary of AAT has been implemented as Lean definitions and theorems under Formal/Arch.

The repository is AlgebraicArchitectureTheoryV2. The proved API is summarized in the Lean definition and theorem index.

The vocabulary used in the second half of this article mainly corresponds to Formal/Arch/Evolution/SignatureDynamics.lean and Formal/Arch/Evolution/AttractorEngineering.lean.

The role of Lean formalization is not to give this theory an aura of correctness. Its role is to record, with boundaries, what can be said under which universe, observation, coverage, and exactness assumptions.

It is important that counterexamples live in the same place as proved theorems.

proved:
  accepted evolution preserves selected invariant
  bounded sampled support-preserving script stays in target region
  selected additive delta telescopes over finite path

proved counterexamples:
  endpoint safe + zero delta does not imply path safe
  accepted preservation does not imply support preservation
  unmeasured axis is not available-zero evidence

Conversely, the fact that something is proved in Lean does not mean that a real-world code extractor is complete, or that every runtime / semantic obstruction has already been observed. With this boundary, AAT can separate what is formally known, what depends on measurement, and what remains an empirical research question.

Conclusion

The discovery of Attractor Engineering changes how I see software architecture: from a static blueprint to a field that guides future changes.

If software architecture is read as an algebraic structure, feature additions and refactorings become operations.

When those operations are repeated, the architecture state draws a trajectory.

We can then ask where that trajectory tends to go, and where it tends to stay. This is where attractors and basins enter the picture.

Architecture design in the era of AI-assisted development can be described as creating a field where future changes gather in good places and can escape bad places.

Harness engineering becomes the engineering of receiving AI's change force, dissipating unwanted components, and guiding the system toward good attractors.

ArchSig is the tool for observing that trajectory.

The essence of AI-assisted development is not only producing PRs faster.

It is deciding where fast force should converge.

A codebase is a field.

A PR is a force.

CI/CD is a dissipative system.

Product managers, product owners, engineers, reviewers, and AI agents are participants in the field.

ArchSig is an observer of the trajectory.

With this framing, development in the AI era is no longer just automation. It becomes field design.

As a design theory for that purpose, Attractor Engineering may be a useful direction for both practice and research.

What is EBICS?

Andr Sv — Sat, 09 May 2026 11:24:18 +0000

If you’ve ever wondered how massive companies move millions of dollars across different banks without losing their minds (or their money), the answer is likely EBICS. Short for Electronic Banking Internet Communication Standard, it is essentially a universal, highly secure language that businesses and banks use to talk to each other.
What exactly is EBICS? Think of EBICS as a secure, high-speed bridge. It started in Germany and has since become the gold standard across Europe—especially in France, Austria and Switzerland for remote data transmission. Instead of every bank using its own clunky, proprietary system, EBICS provides a single, unified gateway. It relies on heavy-duty XML encryption and digital signatures to make sure every byte of data is authenticated and hasn't been messed with. EBICS simplifies the dialogue between businesses and financial institutions, turning complex multi-bank relationships into a streamlined digital workflow.

Get Real Row Counts in GBase 8s Without UPDATE STATISTICS

Michael — Sat, 09 May 2026 11:24:00 +0000

The nrows column in systables is only updated when you run UPDATE STATISTICS, so it often shows 0 even right after bulk inserts. If you need the real, live row count — especially for fragmented tables — you can query sysmaster:sysptnhdr or use oncheck.

Non‑Fragmented Tables

Join systables.partnum with sysptnhdr.partnum in the sysmaster database. sysptnhdr.nrows gives the actual row count and npdata the number of used data pages.

SELECT t.tabname, t.partnum, t.nrows, p.nrows, p.npdata
FROM stores_demo@gbaseserver:systables t,
     sysmaster@gbaseserver:sysptnhdr p
WHERE t.partnum = p.partnum
  AND t.tabname = "customer";

Fragmented Tables

Use sysfragments to get the partition number (partn) and join it with sysptnhdr.partnum to see per‑fragment row counts.

SELECT f.partn, p.nrows, p.npdata
FROM sysfragments f,
     sysmaster@gbaseserver:sysptnhdr p
WHERE f.partn = p.partnum
  AND f.tabname = "tab1";

Quick Check with oncheck

The oncheck -pt command shows row and page counts for a table or fragment immediately, without any statistics update.

oncheck -pt stores_demo:tab1

The output includes sections like Fragment ... Number of rows and Number of pages. It’s a handy operational tool for verifying data volumes in a gbase database.

Responsible Disclosure Case Study: Critical Authorization, Identity and Credential-Exposure Risks Affecting SIPEF-Related Platforms

Anonymous Security Researcher — Sat, 09 May 2026 11:22:06 +0000

Executive Summary

In 2026, I privately disclosed multiple high-severity security concerns affecting systems associated with SIPEF Group, a multinational agro-industrial company operating across Southeast Asia, Africa, and Europe.

The findings included:

a severe Broken Access Control condition affecting the GeoSIPEF sustainability and traceability platform;
publicly indexed credential-exposure indicators associated with enterprise authentication environments;
indicators potentially consistent with infostealer-related compromise scenarios affecting enterprise identities and sessions;
and additional security concerns involving a digital vCard/contact-sharing application associated with the broader enterprise ecosystem.

The issues were disclosed privately under responsible disclosure principles. Following notification, the organization acknowledged receipt, initiated internal triage and containment activities, engaged external specialists, and temporarily disabled affected systems during investigation and remediation activities.

This article intentionally omits exploit-ready details, credentials, sensitive infrastructure information, employee identities, and technical information that could facilitate misuse.

The purpose of this writeup is to discuss:

architectural security lessons;
identity-centric compromise risks;
secure authorization design;
and governance challenges increasingly faced by modern enterprises.

Background

The investigation began through OSINT-based review of publicly visible exposure indicators and externally indexed authentication-related metadata associated with SIPEF-related systems.

The observed indicators included:

enterprise email addresses;
authentication-related URLs;
environment identifiers;
and credential-exposure records indexed in external exposure-intelligence sources.

Examples of publicly visible environment references included:

/GP/Account/LogOn;
production and UAT environment naming patterns;
Microsoft Online authentication contexts;
and enterprise-related login references.

No credentials were purchased, unlocked, validated, or used.

No unauthorized access attempts were performed at any stage.

The findings were handled strictly within responsible disclosure boundaries.

Broken Access Control in GeoSIPEF

One of the most severe findings involved the GeoSIPEF sustainability and traceability platform.

GeoSIPEF was publicly positioned as a digital sustainability and supply-chain traceability initiative supporting ESG and EUDR-related operational visibility.

During review, the application appeared to rely on client-side authorization state stored within browser-accessible storage mechanisms rather than enforcing authorization decisions entirely server-side.

In practical terms, privilege-related state appeared to be trusted on the client side.

This represents one of the most dangerous anti-patterns in modern web security.

Why Client-Side Authorization Is Dangerous

Frontend applications must never be trusted as authorization boundaries.

Anything stored client-side:

localStorage;
sessionStorage;
JavaScript variables;
browser state;
hidden fields;
or client-generated role objects

can potentially be modified by authenticated users.

Authorization decisions must always be enforced server-side.

If authorization logic depends on tamperable client-side state, authenticated low-privileged users may potentially escalate privileges simply by modifying browser-side values.

This category falls under:

OWASP A01:2021 — Broken Access Control.

Broken Access Control consistently remains one of the highest-impact vulnerability classes because it directly affects:

confidentiality;
integrity;
authorization boundaries;
and trust relationships.

Architectural Lessons from GeoSIPEF

The GeoSIPEF case demonstrates several broader architectural lessons relevant across the industry.

1. Frontends are presentation layers — not trust boundaries

Modern SPAs and JavaScript-heavy applications often push excessive logic client-side.

While this improves responsiveness and developer velocity, it creates serious risk if developers blur the distinction between:

UI state and
authorization state.

The browser must always be treated as hostile territory.

2. Sustainability and ESG platforms are now high-value targets

Modern ESG, traceability, and sustainability systems increasingly contain:

supplier data;
operational metrics;
compliance evidence;
land-use information;
audit trails;
and governance reporting.

As organizations digitize sustainability workflows, these systems become increasingly sensitive operational platforms rather than merely “reporting tools.”

Security maturity must evolve accordingly.

3. Governance failures are often architectural failures

Many enterprise security incidents do not originate from advanced attackers.

They originate from:

insecure architectural assumptions;
weak trust-boundary modeling;
rushed development;
insufficient secure-design review;
and lack of server-side authorization validation.

The most dangerous vulnerabilities are often conceptually simple.

Credential Exposure Indicators

Separate from the authorization issue, additional OSINT review identified publicly visible credential-exposure indicators associated with SIPEF-related identities and authentication environments.

The indicators referenced:

Microsoft Online authentication contexts;
enterprise email addresses;
production and UAT naming patterns;
and ERP-related login environments.

Observed indicators suggested possible exposure involving:

enterprise identities;
browser-stored credentials;
or authentication artifacts.

Again:

no credentials were unlocked;
no credentials were validated;
and no login attempts were performed.

The findings were based entirely on publicly visible metadata and exposure indicators.

Infostealer Malware and Modern Identity Risk

Further analysis suggested that at least part of the observed exposure patterns may have been consistent with modern infostealer-related compromise scenarios.

Infostealer malware has become one of the most significant threats facing enterprises today.

Unlike traditional malware focused solely on destruction or ransomware deployment, infostealers specialize in quietly harvesting:

saved browser credentials;
cookies;
refresh tokens;
browser profiles;
cryptocurrency wallets;
VPN credentials;
cloud sessions;
and authentication artifacts.

The resulting datasets are frequently aggregated and redistributed through underground ecosystems.

Why Password Resets Alone Are Sometimes Insufficient

One important industry misconception is that identity compromise equals “password compromise.”

Modern session-centric compromise changes that equation significantly.

If session cookies, refresh tokens, or persistent browser sessions are compromised, attackers may potentially:

bypass certain MFA workflows;
inherit already-authenticated sessions;
or maintain access even after password changes if sessions are not invalidated properly.

This means organizations increasingly need to treat incidents as:

identity compromise events, not merely
password reset events.

Potential Enterprise Impact Areas

Modern identity-centric compromise can potentially affect far more than email access.

Depending on environment integration, risks may extend into:

ERP systems;
VPN environments;
SaaS platforms;
document-management systems;
cloud consoles;
HR systems;
procurement systems;
and financial workflows.

Organizations should therefore consider:

session invalidation;
token revocation;
OAuth consent review;
endpoint forensics;
privileged access review;
and identity telemetry analysis.

Security Concerns in a Digital vCard / Contact-Sharing Application

Separate review activities also identified security concerns affecting a digital vCard/contact-sharing application associated with the broader enterprise ecosystem.

The issues observed were not limited to a single isolated vulnerability pattern, but rather reflected broader concerns around:

trust-boundary enforcement;
client-side assumptions;
exposure of sensitive business-contact information;
and insufficient defensive controls around authenticated application behavior.

Because digital business-card and contact-sharing platforms frequently integrate with:

corporate identity systems;
email environments;
CRM workflows;
and mobile-device ecosystems,

security weaknesses in such applications may create disproportionate downstream risk relative to their perceived operational importance.

Why Digital Identity and Contact Platforms Matter

Enterprise contact-sharing systems are often underestimated from a security perspective.

In reality, they may expose:

employee names;
titles;
reporting structures;
phone numbers;
email addresses;
organizational relationships;
and internal business metadata.

This information can become highly valuable for:

phishing campaigns;
Business Email Compromise;
social engineering;
credential-targeting operations;
and identity correlation activities.

Even seemingly “low-risk” applications can therefore materially increase enterprise attack surface.

Common Architectural Weaknesses in Enterprise Applications

Several recurring anti-patterns commonly appear in internally developed or rapidly deployed enterprise web applications:

excessive trust in client-side state;
insufficient server-side authorization validation;
predictable identifiers or object references;
inadequate segregation between environments;
weak session invalidation controls;
overexposed API responses;
and insufficient input or access validation.

These weaknesses often emerge when:

security review occurs too late in the SDLC;
applications evolve organically without formal architecture review;
or business functionality is prioritized ahead of trust-boundary modeling.

Identity Exposure and Enterprise Reconnaissance Risk

Attackers increasingly combine:

publicly exposed contact information;
credential-exposure datasets;
LinkedIn profiling;
breached browser data;
and cloud identity information

to construct highly accurate targeting maps of organizations.

Applications that expose employee relationship structures, contact metadata, or organizational mappings may unintentionally assist:

phishing operators;
infostealer operators;
BEC actors;
or credential-harvesting campaigns.

This becomes especially concerning when combined with:

weak MFA adoption;
session-token theft;
browser credential storage;
or credential reuse across platforms.

Incident Response and Forensic Considerations

One of the most important lessons from incidents involving possible infostealer activity is the need to preserve evidence early.

Organizations sometimes rush immediately into:

wiping endpoints;
rebuilding machines;
or mass password resets.

While containment is important, preserving:

logs;
endpoint telemetry;
browser artifacts;
token history;
sign-in telemetry;
and authentication trails

is critical for understanding:

infection vectors;
lateral movement;
dwell time;
and post-compromise activity.

Responsible Disclosure Process

The findings described in this article were disclosed privately and in good faith under responsible disclosure principles.

The disclosure emphasized:

non-exploitation;
minimal disclosure;
avoidance of sensitive-data publication;
and coordinated remediation.

The organization acknowledged the report and initiated internal investigation and containment activities.

No public disclosure was performed during the initial remediation period.

Broader Industry Lessons

This case reflects broader trends increasingly affecting enterprises worldwide.

Modern enterprise security challenges are shifting away from traditional perimeter-only threats and toward:

identity compromise;
token theft;
cloud-session abuse;
authorization failures;
and trust-boundary weaknesses.

Organizations must increasingly prioritize:

secure-by-design architecture;
server-side authorization enforcement;
identity governance;
secure SDLC practices;
endpoint hygiene;
and modern session-management controls.

The most damaging failures are often not exotic zero-days.

They are fundamental trust-model mistakes.

Final Thoughts

Security is not merely a tooling problem.

It is fundamentally:

an architectural problem;
a governance problem;
and a trust-boundary problem.

As enterprises accelerate digital transformation initiatives around sustainability, compliance, ERP modernization, cloud identity integration, and business-platform consolidation, secure-design maturity becomes increasingly critical.

Responsible disclosure remains one of the most important mechanisms available for improving security outcomes while minimizing harm.

The goal of disclosure should never be humiliation.

The goal should be:

remediation;
accountability;
architectural improvement;
and stronger security maturity across the industry.

Reposted on Medium - https://medium.com/p/af7f9c24585c and Substack - https://trustboundarylab.substack.com/p/responsible-disclosure-case-study

A VIC x AiSAQ Implementation Brings AI to Your Files Without Breaking the Bank

Ross Peili — Sat, 09 May 2026 11:18:32 +0000

We’re generating more data than ever, and AI‑powered search is great—until your dataset gets huge and your RAM starts crying for mercy. Most vector search systems rely on expensive DRAM to keep indexes fast, but that approach doesn’t scale. KIOXIA’s AiSAQ (All‑in‑Storage ANNS with Product Quantization) flips the script: it runs approximate nearest neighbor search directly on SSD, slashing DRAM usage by 3,200× in billion‑scale workloads. The vic_aisaq_demo repo from ARPA Hellenic Logical Systems puts this tech into a practical, local‑first retrieval pipeline that’s as auditable as it is efficient.

TL;DR: vic_aisaq_demo combines tiered metadata filtering with flash‑optimized vector search to keep memory low and answers relevant. It’s a live demo of storage‑aware AI for edge and controller‑style environments.

The Problem: DRAM Is the Bottleneck

Graph‑based nearest neighbor search (like HNSW) is fast, but it keeps key index structures in DRAM. With billion‑scale datasets, memory costs explode. Even compressed representations can still require tens of gigabytes of RAM. KIOXIA’s AiSAQ technology changes that by moving those compressed vectors to flash storage, consuming as little as 10 MB of DRAM during search without sacrificing recall.

But low DRAM is only half the story. You also need a retrieval strategy that doesn’t waste time parsing irrelevant files.

How `vic_aisaq_demo` Works: Tiered Retrieval Meets Flash‑Native Search

The demo builds on two open‑source building blocks:

lc0_vic – a tiered retrieval controller that plans and orchestrates search in layers (L0 → L1 → L2).
aisaq-diskann – a flash‑oriented ANN backend optimized for low‑DRAM environments.

The execution flow is refreshingly simple:

Librarian / Plan – Turn a natural‑language question into retrieval intent using a lightweight LLM (e.g., qwen2.5:0.5b via Ollama).
L0 Metadata Filter – Narrow down candidate files by extension, size, time, or path hints. Cheap and fast.
L1 Vector Search – Run native AiSAQ ANN search over embeddings to find semantically similar content.
L2 Deep Read – Parse only the top few files and extract evidence snippets.
Ranked Response – Return paths, scores, and run metrics.

The tiered approach keeps deep parsing affordable at scale.

Benchmark results show latency remains stable as dataset size grows, while DRAM footprint stays near zero. The funnel chart below visualises how each tier slashes the candidate pool:

And here’s how the pipeline shifts results from superficial matching to true semantic evidence:

Try It Yourself

The repo is built to be reproducible and local‑first. You’ll need:

WSL (Ubuntu) for building AiSAQ binaries
Ollama running locally (or over the network) with two models:
- Planner model: qwen2.5:0.5b
- Embedding model: embeddinggemma
Python 3.13 and the usual suspects (see requirements.txt)

Once you’ve built the AiSAQ index from a sample drive, a query like:

python3 scripts/run_query.py \
  "Find the Q3 2025 contract that mentions penalty clauses" \
  --aisaq-root /home/$USER/aisaq-diskann

…will return ranked files with evidence snippets, tier labels, and latency metrics.

Why This Matters

vic_aisaq_demo isn’t just a toy. It demonstrates a realistic, storage‑aware retrieval pattern that could run on devices with tight memory budgets—think edge gateways, embedded controllers, or even future SSD firmware that embeds intelligence directly on the drive. The Computational Storage Landscape report maps this evolution, and this repo is one of the first runnable examples that puts those ideas into practice.

The two charts below summarise that systems trade‑off and scaling behaviour:

The takeaway? You don’t need a cluster of DRAM‑heavy servers to run effective semantic search. Sometimes the smartest storage is the one that knows what not to load into memory.

Check out the full repo: ARPAHLS/vic_aisaq_demo

Image to PDF in the Browser - No Libraries, No Backend

TechMind — Sat, 09 May 2026 11:13:20 +0000

As Steve Jobs said, "Design is not just what it looks like and feels like. Design is how it works."

Converting an image to PDF should work like this: open tool → upload image → get PDF. That is it. No backend calls, no third-party APIs, no file size limits from a server.

Here is how it actually works in the browser — and why TechMind.click built it this way.

The Core Approach - Canvas + jsPDF

The cleanest client-side image-to-PDF conversion uses the HTML5 Canvas API and jsPDF:

import { jsPDF } from "jspdf";

async function imageToPDF(imageFile) {
  return new Promise((resolve) => {
    const reader = new FileReader();

    reader.onload = (e) => {
      const img = new Image();
      img.onload = () => {
        // A4 dimensions in mm
        const pdf = new jsPDF({
          orientation: img.width > img.height ? "landscape" : "portrait",
          unit: "mm",
          format: "a4"
        });

        const pageWidth = pdf.internal.pageSize.getWidth();
        const pageHeight = pdf.internal.pageSize.getHeight();

        // Calculate scaled dimensions preserving aspect ratio
        const ratio = Math.min(
          pageWidth / img.width,
          pageHeight / img.height
        );

        const imgWidth = img.width * ratio;
        const imgHeight = img.height * ratio;

        // Center on page
        const x = (pageWidth - imgWidth) / 2;
        const y = (pageHeight - imgHeight) / 2;

        pdf.addImage(
          e.target.result,
          "JPEG",
          x, y,
          imgWidth, imgHeight
        );

        resolve(pdf.output("blob"));
      };
      img.src = e.target.result;
    };

    reader.readAsDataURL(imageFile);
  });
}

Handling Multiple Images

async function multipleImagesToPDF(imageFiles) {
  const pdf = new jsPDF({ unit: "mm", format: "a4" });
  const pageWidth = pdf.internal.pageSize.getWidth();
  const pageHeight = pdf.internal.pageSize.getHeight();

  for (let i = 0; i < imageFiles.length; i++) {
    if (i > 0) pdf.addPage();

    const dataUrl = await fileToDataURL(imageFiles[i]);
    const dimensions = await getImageDimensions(dataUrl);

    const ratio = Math.min(
      pageWidth / dimensions.width,
      pageHeight / dimensions.height
    );

    pdf.addImage(
      dataUrl, "JPEG",
      (pageWidth - dimensions.width * ratio) / 2,
      (pageHeight - dimensions.height * ratio) / 2,
      dimensions.width * ratio,
      dimensions.height * ratio
    );
  }

  return pdf.output("blob");
}

const fileToDataURL = (file) => new Promise((res) => {
  const reader = new FileReader();
  reader.onload = (e) => res(e.target.result);
  reader.readAsDataURL(file);
});

const getImageDimensions = (src) => new Promise((res) => {
  const img = new Image();
  img.onload = () => res({ width: img.width, height: img.height });
  img.src = src;
});

Why Client-Side Matters

As Alan Turing would appreciate — the most elegant solution solves the problem with the least complexity. Client-side conversion means:

Zero server costs — no file storage, no bandwidth for uploads
Privacy — user files never leave their device
Speed — no round-trip to a server
Offline capable — works without internet after initial page load

Quick Manual Fix

For non-developers or one-off conversions, TechMind.click has this built in — upload image, download PDF, done. Uses the same browser-based approach — no server, no storage.

What is your preferred client-side PDF library? jsPDF vs pdf-lib — drop it in the comments.

Desconstruindo o Streaming do Naver: Como Construir um Downloader de Alta Performance com HLS e WebAssembly

yqqwe — Sat, 09 May 2026 11:12:21 +0000

Para o usuário comum, baixar um vídeo parece ser apenas uma questão de encontrar um link .mp4. No entanto, para desenvolvedores que lidam com plataformas gigantes como o Naver (incluindo Naver TV, Sports e arquivos do V LIVE), a realidade é uma infraestrutura fragmentada, protegida e altamente otimizada via Adaptive Bitrate Streaming (ABS).
Ao desenvolver o Naver Video Downloader, enfrentei desafios técnicos que foram muito além do simples web scraping. Neste artigo, vou detalhar a arquitetura de entrega de vídeo do Naver e as soluções de engenharia que implementamos para alcançar uma extração sem perdas e de alta velocidade.

1. O Desafio Central: O Vídeo "Invisível"

O Naver não serve arquivos de vídeo estáticos. Eles utilizam o protocolo HLS (HTTP Live Streaming).
1.1 O Fluxo Fragmentado
Quando você reproduz um vídeo no Naver, seu navegador não está baixando um único arquivo; ele está baixando centenas de pequenos segmentos .ts (Transport Stream).
• Master Playlist (.m3u8): Um arquivo de manifesto que lista todas as resoluções disponíveis (1080p, 720p, etc.).
• Media Playlist: Um sub-manifesto para uma resolução específica contendo as URLs dos segmentos individuais de 2 a 5 segundos.
1.2 A Barreira de Autenticação: VodSeed e Tokens Dinâmicos
A API interna do Naver (vod_play_info) é o "cérebro" do player. Para obter o link .m3u8, você precisa de um vid (Video ID) e um inkey (Session Key). Essas chaves são frequentemente geradas via JavaScript ofuscado e possuem um TTL (Time To Live) muito curto. Tentar acessar uma URL de segmento sem a assinatura correta resulta em um erro 403 Forbidden.

twittervideodownloaderx.com

2. Engenharia do Mecanismo de Extração

Para automatizar isso, nosso motor deve emular um "handshake" entre o player oficial do Naver e seu backend.
2.1 Interceptação de Metadados
Implementamos uma lógica de análise headless que:

Escaneia a página de destino em busca do vid — geralmente oculto em um objeto JSON PRELOADED_STATE.
Simula a chamada de API para os servidores VOD do Naver usando um conjunto rotativo de cabeçalhos que imitam impressões digitais de navegadores reais.
Analisa o XML/JSON retornado para encontrar a fonte M3U8 de maior bitrate (geralmente 1080p).

3. Superando o CORS: Arquitetura de Proxy Transparente

Os navegadores aplicam a Política de Mesma Origem (SOP). Um script em seu-site.com não pode buscar dados binários diretamente dos domínios do naver.com devido às restrições de CORS (Cross-Origin Resource Sharing).
3.1 Proxy de Streaming de Alta Taxa de Transferência
Para resolver isso, construímos um Proxy de Streaming Transparente usando Node.js.
• O Fluxo: O cliente solicita um segmento através do nosso proxy. Nosso servidor o busca no CDN do Naver, remove os cabeçalhos CORS restritivos e injeta Access-Control-Allow-Origin: *.
• Zero-Latency Piping: Em vez de baixar o segmento inteiro para o nosso servidor primeiro, usamos Stream Piping. Os dados são enviados ao usuário conforme chegam, o que significa que nosso servidor atua como um "tubo passivo", mantendo o uso de RAM constante, independentemente do tamanho do vídeo.

4. Muxing no Lado do Cliente com FFmpeg.wasm

É aqui que a mágica acontece. Unir 500 arquivos .ts individuais em um servidor é intensivo em CPU e caro. Em vez disso, descarregamos o trabalho para o computador do usuário via WebAssembly (WASM).
4.1 Remuxing vs. Transcoding
Os segmentos de vídeo no fluxo HLS do Naver já estão codificados em H.264. Codificá-los novamente perderia qualidade e levaria muito tempo. Usando o FFmpeg.wasm, realizamos o Remuxing:
• Utilizamos a flag -c copy no FFmpeg.
• Isso instrui o motor a apenas mudar o "container" de TS para MP4 sem tocar nos pacotes de vídeo subjacentes.
• Resultado: Qualidade 1080p nativa, processada em segundos diretamente na memória RAM do navegador do usuário.

5. Otimizações de Performance

5.1 Controle de Concorrência Assíncrona
Baixar 500 segmentos um por um é lento. Baixar todos de uma vez aciona o limite de taxa (rate-limiting) do CDN. Implementamos um Async Promise Pool para manter exatamente 5 a 10 downloads simultâneos, maximizando a largura de banda sem ser bloqueado.
JavaScript
// Lógica conceitual para download paralelo
async function downloadWithPool(urls, limit) {
const pool = new Set();
for (const url of urls) {
if (pool.size >= limit) await Promise.race(pool);
const promise = fetchSegment(url).then(() => pool.delete(promise));
pool.add(promise);
}
}
5.2 Alinhamento de Dados Sequenciais
Os segmentos HLS devem ser unidos na ordem exata especificada no arquivo .m3u8. Mesmo um único segmento ausente pode dessincronizar o tempo de áudio e vídeo. Nosso motor implementa uma Camada de Validação de Sequência que tenta baixar novamente chunks que falharam e garante que o buffer binário esteja perfeitamente alinhado antes da fase final de muxing.

6. Conclusão: Engenharia para Privacidade e Velocidade

Construir um downloader para uma plataforma tão complexa quanto o Naver é uma aula de arquitetura web moderna. Ao combinar proxies Node.js, análise de HLS e WebAssembly, criamos uma ferramenta que é rápida, eficiente e focada na privacidade.
Se você está procurando uma maneira confiável de salvar conteúdo do Naver na qualidade original 1080p, experimente nossa ferramenta: 👉 Naver Video Downloader
Destaques Técnicos:
• Qualidade Nativa: Sem compressão adicional; cópia 1:1 do stream original.
• Potencializado por WASM: Todo o processamento ocorre no lado do cliente para máxima privacidade.
• Sem Instalação: Funciona inteiramente no navegador usando padrões web modernos.
Dúvidas sobre análise de HLS ou WebAssembly? Vamos discutir nos comentários abaixo!

Tags: #JavaScript #WebDev #NodeJS #WebAssembly #FFmpeg #Naver #Streaming #Architecture

📢Angular’s 7‑Layer Component Architecture 🗂️

abdelaaziz ouakala — Sat, 09 May 2026 11:11:12 +0000

📢 𝐌𝐨𝐬𝐭 𝐀𝐧𝐠𝐮𝐥𝐚𝐫 𝐟𝐨𝐥𝐝𝐞𝐫𝐬 🗂️ 𝐥𝐨𝐨𝐤 𝐥𝐢𝐤𝐞 𝐚 𝐣𝐮𝐧𝐤 𝐝𝐫𝐚𝐰𝐞𝐫 🤨 . 𝐇𝐞𝐫𝐞 𝐢𝐬 𝐭𝐡𝐞 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 𝐈 𝐮𝐬𝐞 𝐟𝐨𝐫 𝟏𝟎𝟎+ 𝐜𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭 𝐚𝐩𝐩𝐬.

This is what happens when every component, directive, and service lives in one chaotic folder. It looks harmless at first — until onboarding slows, bugs multiply, and scalability collapses.

🚨 The Hook
Most Angular apps don’t fail because of performance — they fail because of folder chaos.
When your src/app looks like a junk drawer, you’re not just messy… you’re building a maintenance nightmare.

🧩 The Problem
Flat folders = high cognitive load.
When a new engineer joins and sees 50+ components in one directory, they aren’t onboarding — they’re firefighting.

The infamous shared/components folder becomes a dumping ground. Over time, this erodes scalability, testability, and maintainability.

🏗️ The 7‑Layer UI System
To solve this, I move teams from “Flat Chaos” → 7‑Layer UI System.
This isn’t about aesthetics; it’s about enforcing the Single Responsibility Principle (SRP) at the architectural level.

The Hierarchy

Elements → Atomic UI (Buttons, Inputs). Pure, dumb, zero logic.
Blocks → UI Compositions (Cards, Hero sections).
Features → Smart layer (Signals, APIs, service injection).
Dialogs → Wizards, Modals, isolated flows.
Layouts → Dashboards, Nav shells.
Views → Route orchestration. Where features meet the router.
Domains → Business boundaries (Billing, Auth, Analytics).

📂 Folder Structure Example
Here’s how it looks in practice:

src/app/
└── modules/
    └── billing/                <-- [L7: Domain]
        ├── layouts/            <-- [L5: Layout]
        ├── views/              <-- [L6: View]
        │   └── invoice-list/
        ├── features/           <-- [L3: Feature]
        │   └── payment-form/
        ├── dialogs/            <-- [L4: Dialog]
        ├── blocks/             <-- [L2: Block]
        │   └── invoice-card/
        └── elements/           <-- [L1: Element]
            └── status-badge/

This structure scales naturally to 100+ components without collapsing under cognitive load.

“Order Restored: The 7‑Layer Architecture”

Each folder now has a clear purpose — from atomic Elements to business Domains. The hierarchy enforces boundaries, reduces cognitive load, and makes scaling feel effortless.

📊 Architecture Diagram Ideas
Two visuals make this system click:

Pyramid of Responsibility → Elements at the wide base (many, simple), Domains at the peak (few, complex).

Dependency Flow → Arrows only downward. Blocks can use Elements, but Elements never depend on Features.

These diagrams reinforce the mental model: granular → functional → contextual.

💡 Key Benefits
Breaking it down:

Scalability → Independent vertical features (e.g., feat-auth, feat-users) allow teams to work in parallel.

Testability → Dumb components and pure services are easy to unit test.

Maintainability → Clear boundaries ensure changes in one layer don’t ripple into others.

This aligns with Clean Architecture principles while staying pragmatic for frontend teams.

⚡ Contrarian Engineering Opinion
“The shared/ folder is where good code goes to die.”

If you can’t categorize a component into a specific domain or layer, you don’t understand its purpose yet.
Shared folders encourage laziness and blur boundaries — the exact opposite of scalable architecture.

📚 Case Study
On one enterprise project, the team started with a flat components/ folder. Within months:

Onboarding slowed to a crawl.
Testing became inconsistent.
Refactors broke unrelated features.

After migrating to the 7‑Layer system:

New engineers onboarded in days, not weeks.
Unit tests mapped cleanly to Elements/Blocks.
Features scaled independently with Nx libraries.

The difference wasn’t performance — it was cognitive clarity.

✅ Conclusion
Performance isn’t what kills Angular projects. Cognitive load does.

By enforcing the 7‑Layer UI System, you prevent “God Components,” reduce chaos, and scale cleanly past 100+ components.

How do YOU structure Angular apps at scale?

Nx libraries
Domain‑driven folders
Or the “hope for the best” flat structure?

Drop your approach — and your battle scars — in the comments.

🌐 Connect With Me
If you enjoyed this deep dive into Angular architecture and want more insights on scalable frontend systems, follow my work across platforms:

🔗 LinkedIn — Professional discussions, architecture breakdowns, and engineering insights.
📸 Instagram — Visuals, carousels, and design‑driven posts under the Terminal Elite aesthetic.
🧠 Website — Articles, tutorials, and project showcases.
🎥 YouTube — Deep‑dive videos and live coding sessions.

Angular #SoftwareArchitecture #WebDevelopment #Nx #Frontend #CleanCode #ProgrammingTips

How to Prepare a Legacy Codebase for AI-Assisted Refactoring

137Foundry — Sat, 09 May 2026 11:09:29 +0000

Jumping into a legacy codebase with an AI coding assistant and no preparation produces predictably mixed results. The AI generates plausible-looking refactors that miss critical business logic embedded in unexpected places. You spend more time verifying output than the AI saved you in generation time. And the refactored code, while cleaner-looking, may have subtle behavioral changes that surface in production six weeks later.

The difference between this outcome and a productive AI-assisted modernization session is preparation. Specifically: giving the AI the context it needs to reason correctly about your specific codebase rather than reasoning from generic patterns.

This guide covers the preparation steps that make AI-assisted legacy refactoring significantly safer and more productive.

Step 1: Establish Scope and Document It

Before any AI interaction, define the boundary of what you are working on. Legacy codebases have a way of expanding scope because everything touches everything. Resist this.

Choose a specific module, class, or set of related functions as your working scope. Write a plain-language description of what that scope is responsible for:

Scope: the discount calculation module (discount.py, approximately 400 lines)
This module is responsible for: calculating the final price a customer pays
after applying applicable discounts, promotions, and loyalty tier benefits.

It is NOT responsible for: fetching customer tier data (done by customer_service.py),
validating promo codes (done by promo_validator.py), or applying tax (done post-discount
by tax_calculator.py).

The most important business constraint: discounts do not stack additively.
A customer with a 20% loyalty discount and a 15% promo code gets 20% off, 
not 35% off. This is intentional and must be preserved in any refactoring.

This description becomes the context header you paste before every AI prompt related to this module. It costs you twenty minutes to write; it saves you from explaining the same context to the AI repeatedly and catching errors that stem from the AI not knowing the "discounts don't stack" rule.

Step 2: Audit Dependencies Before Touching Anything

AI coding assistants will generate refactored code that changes function signatures, return types, or module interfaces without knowing what depends on them. Before you start refactoring, you need a dependency map.

For Python codebases, tools like Python's built-in ast module and import analysis scripts can generate call graphs. For JavaScript, ESLint and module analysis tools serve a similar purpose. GitHub advanced search can help you find all internal references to a specific function across a large repository.

The AI can help with this phase, but its output should be treated as a starting point:

Identify all the places this function is called in the following files.
For each call site, note:
1. The file and line number
2. How the return value is used (stored, compared, iterated over, etc.)
3. Whether the caller passes keyword arguments or positional arguments

[target function] [relevant surrounding files]

Review the AI's output carefully. Dynamic call patterns (calling functions stored in dictionaries, factory patterns, monkey-patching) will not appear in AI dependency analysis. These need manual identification.

The dependency map serves a critical purpose: before you change a function signature or return type, you know what you need to update. Without it, you are refactoring blind.

Step 3: Create a Test Baseline

Legacy code with no tests is the most dangerous to refactor because you have no automated way to verify that behavior is preserved. Before any refactoring, use AI to generate an initial test suite for the module you are working on.

This is one of the highest-value uses of AI assistance in legacy modernization. Even imperfect AI-generated tests are faster to produce than writing them from scratch, and they provide a safety net that makes subsequent refactoring significantly lower-risk.

Important: AI-generated tests tend to cover the happy path and obvious error cases well, and miss edge cases that emerged from production incidents. After getting the AI-generated test suite, review your issue tracker, Git blame history, and incident reports for the module. Add tests for any bugs that were fixed in the module's history - those are the edge cases most likely to be reintroduced by refactoring.

Once your test baseline is in place, configure your CI pipeline to run these tests on every commit. This gives you immediate feedback when a refactoring breaks behavior.

Step 4: Identify and Document the Critical Paths

Not all code in a legacy system is equally risky to modify. The critical paths are the execution flows that:

Handle money or anything irreversible (payments, emails sent, database deletes)
Run under high load or in performance-sensitive paths
Have known security relevance (authentication, authorization, input validation)
Have produced incidents or bugs in the past

These are the paths where AI-generated refactors need the most careful human review. Document them explicitly before starting:

Critical paths in discount.py:
1. Lines 145-190: Final discount application to cart total - this writes to the order record
2. Lines 210-230: Promo code validation bypass for internal employee accounts - security-relevant
3. Lines 280-310: Bulk discount calculation - runs for every item in large orders, performance-sensitive

When AI-generated refactors touch lines in this list, they get extra review. When they do not, you can move faster. This simple classification reduces the time you spend being careful about everything and focuses attention where it matters.

Photo by Bernice Chan on Pexels

Step 5: Set Up a Safe Experimentation Environment

Before merging any AI-assisted refactoring, you need a way to run the original and refactored code side-by-side and compare behavior. The ideal setup:

A feature branch where AI-assisted changes are isolated
Your test baseline running against both the original and the refactored code
If the module has external side effects (database writes, external API calls), a way to stub those out for comparison testing

Martin Fowler's branch-by-abstraction pattern is useful for large-scale refactoring: introduce a seam that lets you run old and new implementations in parallel and compare results before fully switching.

For simpler modules, a straightforward A/B test in a staging environment - routing a portion of traffic to the refactored implementation - gives you confidence before full deployment.

Putting It Together

The preparation sequence - scope definition, dependency audit, test baseline, critical path identification, safe environment setup - takes time. On a module of moderate complexity, expect to spend a day on preparation before writing a line of refactored code.

That investment pays back quickly. With context documents, a test baseline, and a dependency map in hand, each AI-assisted refactoring session produces output that is faster to review, safer to merge, and less likely to produce production incidents.

For the full framework on running these sessions - including prompting patterns for the refactoring phase itself - the guide on using AI coding assistants for legacy code modernization covers the end-to-end process.

137Foundry works with engineering teams on legacy modernization assessments and implementation. The 137Foundry AI automation services include preparation consulting for teams starting this process for the first time.

Prettier and ESLint are useful tools for establishing consistent code style as a baseline before starting structural refactoring - style differences in a diff make behavioral changes harder to spot. OWASP provides useful checklists for security-critical code review that apply directly to the critical path review step.

Legacy modernization done well is not fast. But with the right preparation, AI assistance makes it substantially less expensive than it used to be.

Open Forem

Postgres Tells You Your Query Was Slow. Not Which Index Was Wasted.

The Gap in Postgres's Stats

File 1: The Wrapper (query-logger.ts)

Why Not pg_stat_statements or auto_explain?

EXPLAIN Without ANALYZE

The Wrapper

The One Pattern That Matters: Fire-and-Forget

File 2: The Table (query_logs)

File 3: The Dashboard

What It Found

The 2,552 kB Index Nobody Has Ever Used

The Barely-Used Tier

5 Things I Learned Building This

1. Index stats don't equal index value

2. EXPLAIN without ANALYZE is your friend

3. Sample — don't measure every query

4. The dimensions are the product

5. Indexes are a cost, not a feature

What to Add When You're Ready

The Bottom Line

I Built These Tools Because the Frustration Was Real

1. TermiCool — Because Terminal Customization Shouldn’t Feel Like Surgery

2. TreePress — Because PDF Export Shouldn’t Destroy Your Work

3. CCL — Because Rebuilding Claude Code Setup Was Repetitive

None of This Was Planned

If You’re Facing the Same Friction

Your Turn

Building an Authentication Starter: Lessons from Integrating Next.js, PostgreSQL, Prisma, and NextAuth

Building an Authentication Starter: Lessons from Integrating Next.js, PostgreSQL, Prisma, and NextAuth

The Foundation: Why These Technologies?

Next.js

PostgreSQL & Prisma

NextAuth.js

Additional Tools

Key Features I Focused On

How the Project is Organized

Insights and Lessons Learned

Concluding Thoughts

Repo:

Attractor Engineering: Seeing Software Development as Field Dynamics

The First Discovery

A Codebase Is a Field, and a PR Is a Force

People and Systems Create the Field

What Changes in AI-Assisted Development

What Is an Attractor?

What Is Attractor Engineering?

Harness Engineering as a Dissipative System

What ArchSig Observes

PRs Become More Important, Not Less

Future Development Organizations

Summary So Far

From Here, in Mathematical Language

A Short Introduction to AAT

Formalizing Attractor Dynamics

1. State, Operation, Observation

2. PR Force Model

3. Three Classes of Force

4. A Chaos-Game-Like Correspondence

5. Support Shaping

6. The Same Signature Does Not Imply the Same Future

7. Accepted Preservation and Support Preservation Are Different

8. PRs Are Non-Commutative

9. Observe the Shape of the Trajectory

10. Expanding Observation Can Suddenly Reveal Badness

About the Lean Formalization

Conclusion

What is EBICS?

Get Real Row Counts in GBase 8s Without UPDATE STATISTICS

Non‑Fragmented Tables

Fragmented Tables

Quick Check with oncheck

Responsible Disclosure Case Study: Critical Authorization, Identity and Credential-Exposure Risks Affecting SIPEF-Related Platforms

Executive Summary

Background

Broken Access Control in GeoSIPEF

Why Client-Side Authorization Is Dangerous

Architectural Lessons from GeoSIPEF

1. Frontends are presentation layers — not trust boundaries

2. Sustainability and ESG platforms are now high-value targets

File 1: The Wrapper (`query-logger.ts`)

File 2: The Table (`query_logs`)

How `vic_aisaq_demo` Works: Tiered Retrieval Meets Flash‑Native Search