Forem: Soumia

What KubeCon Amsterdam 2026 Taught Me About Infrastructure as Transformation

Soumia — Fri, 08 May 2026 11:44:49 +0000

KubeCon + CloudNativeCon EU 2026 · Amsterdam · March 23–26

More than 13,000 engineers gathering around infrastructure might sound excessive until you realize what they're really there for: understanding how the next generation of systems is being built in real time.

All sessions referenced in this article are available through the CNCF KubeCon recordings.

The Why

I almost didn't go.

KubeCon felt overwhelming—too big, too technical, too crowded. But something about the energy of thousands of engineers gathering around the future of infrastructure made the trip worth it.

Not for the keynotes or the networking (though both mattered). I went because infrastructure is changing faster than most organizations can operationalize it, and I wanted to understand where the ecosystem was converging.

What I found was not a week of dramatic announcements or paradigm shifts.

It was something more interesting: operational maturity.

Across sessions, hallway conversations, and product announcements, the same themes kept repeating:

observability moving deeper into the kernel,
platform engineering focusing on developer cognition,
AI workloads becoming operational infrastructure,
and agentic systems forcing teams to rethink reliability entirely.

What became clear by the end of the week was this:

The cloud-native ecosystem is beginning to build the operational layer for AI agents the same way it once built the operational layer for containers—incrementally, pragmatically, and one infrastructure problem at a time.

01. LLM Inference on Kubernetes: Infrastructure Becomes the Product

The GKE session on optimizing large language models on Kubernetes was the first talk that shifted my perspective.

Not because it introduced radically new ideas, but because the conversation felt deeply operational.

The core challenge was straightforward:
LLMs are not typical workloads.

Inference systems introduce sustained resource pressure across networking, scheduling, memory allocation, and accelerator management in ways many Kubernetes environments were not originally designed for.

The session covered:

model serving frameworks like vLLM, TGI, Triton, and Ray Serve,
Kubernetes Dynamic Resource Allocation (DRA),
GPU orchestration,
and increasingly sophisticated networking strategies for inference optimization.

One recurring theme was KV cache efficiency and routing.

Not because it is flashy, but because inference optimization increasingly comes down to infrastructure efficiency rather than model novelty.

What stood out most was how normalized these conversations felt.

AI infrastructure discussions at KubeCon no longer sounded experimental. They sounded operational.

The Learning

The challenge with AI workloads is increasingly operational rather than conceptual.

Model access is becoming commoditized.
Reliable orchestration, scheduling, observability, and cost control are becoming the differentiators.

02. Backstage & the Philosophy of Developer Experience

Spotify's talk on Backstage was one of the more interesting non-technical sessions of the week.

A story from the session stayed with me:
Spotify teams had experienced the familiar problem many fast-growing engineering organizations encounter—operational knowledge becoming fragmented across tools, documentation systems, spreadsheets, ownership records, and tribal knowledge.

The example illustrated a broader organizational truth:
engineering complexity often grows faster than internal systems evolve to manage it.

Backstage emerged from Spotify's effort to centralize operational context and developer workflows into a more coherent platform experience.

What matters here is not only the tool itself, but the philosophy behind it.

Developers should not need deep infrastructure expertise simply to deploy software safely and reliably.

Backstage approaches this by treating operational metadata as infrastructure:

ownership information,
deployment workflows,
dependency visibility,
templates,
scorecards,
and documentation become integrated directly into the developer workflow.

What stood out was how operational context became centralized into a single interface.

Backstage was not acting like a dashboard.
It was acting more like an internal platform layer for developers.

The most important insight from the session was organizational rather than technical:
platform engineering succeeds when it reduces cognitive fragmentation.

The Learning

The strongest platform teams optimize for cognitive clarity as aggressively as they optimize for system reliability.

Golden paths scale better than undocumented complexity.

03. Cross-AZ Observability & the Real Cost of Visibility

Miro's session on cross-AZ observability costs highlighted something many teams underestimate:
observability architecture itself can become a significant infrastructure cost center.

When workloads run across availability zones, metrics and telemetry crossing network boundaries generate measurable egress costs.

At scale, observability design decisions become infrastructure decisions.

Miro discussed a relatively straightforward but effective pattern:
zone-aware scraping.

Prometheus scraped local targets, aggregated locally, and minimized unnecessary cross-zone metric transfer.

The session also highlighted VictoriaMetrics, which has gained attention for focusing heavily on efficiency and operational simplicity in metrics storage.

What made the talk compelling was not novelty.
It was practicality.

The operational maturity of cloud-native infrastructure increasingly depends on efficiency optimization at every layer.

What Happened Post-KubeCon

Shortly after KubeCon:

Splunk announced OpenTelemetry eBPF Instrumentation (OBI) in beta,
and Grafana continued integrating projects like Beyla into broader OpenTelemetry workflows.

The larger trend is becoming clearer:
observability instrumentation is moving closer to the kernel layer through eBPF, while operational standards increasingly converge around OpenTelemetry.

The Learning

At scale, observability becomes an architectural discipline rather than simply a tooling choice.

Tooling amplifies operational design decisions already embedded into the system.

04. AI Agents & Platform Engineering: Reliability for Non-Deterministic Systems

The panel on AI Agents & Platform Engineering was the session that tied many of the week's themes together.

Panelists:

Idit Levine (Solo.io)
Vincent Caldeira (Red Hat)
Hasith Kalpage (Cisco)
Sara Qasmi (United Nations)
Carlos Santana (AWS, moderator)

The central tension discussed throughout the panel was this:

AI agents are probabilistic systems operating inside infrastructure environments historically optimized for deterministic behavior.

Traditional platform engineering assumes:

reproducibility,
consistency,
predictable deployments,
and stable execution paths.

Agentic systems challenge many of those assumptions.

The conversation repeatedly returned to observability, evaluation, and governance.

Rather than forcing agents into deterministic behavior models, the emerging operational pattern appears to focus on:

continuous evaluation,
instrumentation,
permissions boundaries,
and measurable reliability.

One of the strongest moments from the panel came from Vincent Caldeira:

"Agentic vulnerability is statistical, not deterministic."

That framing changes the operational question entirely.

Instead of asking:

"Is this system perfectly safe?"

Teams increasingly ask:

"Is this system measurably safer, more observable, and more governable than the existing human process?"

Another concept discussed heavily was the emergence of reusable "Skills" and tool abstractions for agents.

The architecture forming around agentic systems increasingly resembles familiar cloud-native operational patterns:

modular capabilities,
registries,
sandboxed execution,
observability,
and governance layers.

What Happened at KubeCon (and After)

Solo.io announced:

agentevals — an open-source framework for evaluating agent behavior using OpenTelemetry.
agentregistry donated to the CNCF ecosystem — focused on centralized discovery and governance for agents and tools.

These announcements felt notable not because they solved everything, but because they suggested the ecosystem is beginning to standardize operational patterns for agentic infrastructure.

The Learning

The shift from LLMs to agents is not simply about smarter models. It is about infrastructure adapting to probabilistic operational systems.

Observability, evaluation, governance, and orchestration are becoming foundational concerns.

The North Star: Where the Ecosystem Appears to Be Going

By Thursday afternoon, several patterns had become difficult to ignore.

The same operational themes kept surfacing:

platform engineering,
eBPF,
OpenTelemetry,
AI infrastructure,
operational efficiency,
and governance.

Three broader shifts stood out.

1. Platform Engineering ↔ eBPF

Infrastructure conversations are increasingly moving simultaneously:

upward toward developer experience,
and downward toward kernel-level visibility and security.

eBPF sits at the center of that transition.

Instrumentation is becoming more deeply integrated into infrastructure itself while becoming increasingly invisible to developers.

2. AI on Kubernetes Is Becoming Operational Infrastructure

AI workloads are rapidly becoming standard platform concerns.

Platform teams are now regularly discussing:

GPU scheduling,
inference networking,
accelerator orchestration,
model serving reliability,
and operational cost control.

The tooling ecosystem around Kubernetes AI workloads is maturing quickly.

3. Efficiency Is Becoming a Core Operational Metric

Energy usage, infrastructure efficiency, observability overhead, and GPU utilization are increasingly treated as operational concerns rather than secondary optimizations.

The broader trend is not only about sustainability messaging.
It is also about economic reality.

Efficient infrastructure compounds.

What This Means for Platform Teams

Several practical themes emerged repeatedly throughout the week.

Understand Observability as Infrastructure

Observability is no longer just a monitoring layer.

It increasingly shapes architecture, reliability, debugging, governance, and operational cost.

Prepare for Agentic Workloads

Even organizations not deploying agents today are beginning to think about:

evaluation,
permissions,
governance,
sandboxing,
and auditability.

The operational questions are arriving quickly.

Efficiency Is Becoming Strategic

Cloud costs, telemetry overhead, and infrastructure efficiency are becoming platform-level concerns.

Operational efficiency increasingly creates long-term competitive advantages.

Developer Experience Is Infrastructure Work

The strongest platform teams reduce cognitive overhead.

They centralize operational context.
They provide safe defaults.
They simplify complexity without hiding it.

That is infrastructure engineering now.

The Real Value of KubeCon

At some point during a conference like KubeCon, you stop trying to absorb every session.

You start paying attention to the patterns connecting them.

That was the most valuable part of the week for me.

Not only the talks themselves, but the conversations afterward:

engineers comparing operational tradeoffs,
platform teams solving similar scaling problems independently,
and a growing sense that infrastructure is evolving faster than most organizations can fully absorb.

The cloud-native ecosystem in 2026 feels less experimental than it did several years ago.

The tooling is maturing.
The operational patterns are stabilizing.
The architectural layers are becoming clearer.

And the next frontier—agentic systems, kernel-level observability, and infrastructure efficiency—appears to be emerging from the same engineering discipline that previously shaped the container ecosystem itself.

The most valuable reminder from KubeCon is that these are collective problems.

Thousands of engineers are iterating toward similar operational solutions at the same time.

Go watch the sessions.
But more importantly, operationalize one useful idea inside your own systems.

That is where transformation actually happens.

Infrastructure is no longer simply supporting transformation. Increasingly, it is becoming the mechanism through which transformation happens.

Resources

This article draws from sessions and discussions involving Google Cloud, Spotify Engineering, Miro, Solo.io, Red Hat, Cisco, AWS, and other contributors across the cloud-native ecosystem.

By Soumia — LinkedIn · Portfolio

Are you working on something similar? Drop a comment — I'm curious what you're building and what you're seeing in your own work.

5 Things You Can Do Right Now to Know Where You Stand on EU AI Act & GDPR Compliance

Soumia — Thu, 07 May 2026 11:21:29 +0000

The Act: New & Old explores how Europe wrote the first comprehensive AI law on Earth, and how that law is now colliding with the urgency to build. But knowing the law exists is different from knowing whether your systems comply with it.

As we approach the August 2, 2026 enforcement deadline for high-risk systems, the window for "guessing" is closing. Here are five concrete actions you can take immediately — whether you're an individual builder on Lovable, a small team, or an organization deploying AI-powered tools in the EU.

1 · Classify Your System: Is It High-Risk?

Start here. Under the EU AI Act's Annex III, high-risk systems include AI that:

Influences hiring, promotion, or termination decisions
Assesses creditworthiness or insurance eligibility
Determines access to education or training
Analyzes biometric data or influences civil rights
Processes personal data at scale in ways that affect significant life outcomes

Action item

[ ] Spend 30 minutes asking: Does my system influence a decision that affects someone's rights, access, or opportunities? If yes, you aren't just a user; you are likely a "Provider" or "Deployer" of a high-risk system.

Tool: Use the EU AI Act Compliance Checker for a formal assessment.

2 · Conduct a Dual Impact Assessment (DPIA + FRIA)

If your system processes personal data, a Data Protection Impact Assessment (DPIA) is a GDPR requirement. However, for high-risk AI in 2026, you must also consider the Fundamental Rights Impact Assessment (FRIA).

	Focus
DPIA	Data privacy and security
FRIA	Societal risks — algorithmic bias, discrimination, or threats to human dignity

Action item

[ ] Document the data flow, identify risks to individuals (not just their data), and list your safeguards. This is your accountability "paper trail" for regulators.

3 · Secure a Data Processing Agreement (DPA) from Every Vendor

If you use Lovable, OpenAI, or Anthropic, they are your sub-processors. A DPA establishes who is responsible if a breach occurs.

Action items

[ ] Download and sign the Lovable DPA at lovable.dev/data-processing-agreement.
[ ] Maintain a "Vendor Map" of every AI API your app calls. In 2026, ignorance of your supply chain is not a legal defense.

4 · Build Your Technical Documentation & Quality Management

Documentation separates "we tried" from "we complied." For high-risk systems, you need a technical file that proves your system is accurate, robust, and cyber-secure.

The 2026 Standard

To make this easier, look into ISO 42001 (the international standard for AI Management). Following this "Gold Standard" creates a Presumption of Conformity, making it much harder for regulators to challenge your process.

Action item — create a "living document" that lists:

[ ] How humans can override the AI (Human Oversight)
[ ] How you tested for bias (Data Governance)
[ ] Your plan for Post-Market Monitoring (how you'll track the AI's performance once it's live)

5 · Implement Transparency & Labeling

By 2026, "hidden" AI is illegal in the EU. If a human is interacting with an AI, they must know it.

Action items

[ ] UI/UX: Add clear disclosures (e.g., "This response was generated by AI").
[ ] Deepfakes / Media: If your tool generates images or audio that look real, they must be digitally watermarked or labeled as AI-generated.
[ ] The CE Mark: If you are a Provider of a high-risk system, you will eventually need to affix a CE Mark to your product once you've completed your self-assessment.

What's Next?

These five items won't make you 100% compliant — genuine compliance is a marathon — but they will:

Grant you a "First-Mover" Advantage: Most organizations are still scrambling; having your documentation ready by August 2026 puts you ahead.
Protect your Brand: Transparency builds user trust, which is the most valuable currency in the AI era.
Create a Defensible System: If a regulator knocks, you have a PDF ready to show them.

If you're building on Lovable

Lovable handles the infrastructure security and data residency. You own the "Application Layer" — the transparency, the impact assessments, and the human oversight. Together, this creates a system that is both innovative and legally defensible.

Resources to Keep Handy

EU AI Act Service Desk: official link
ISO 42001 Overview: the roadmap for AI Management Systems.
GDPR Article 35: guidelines for DPIAs.

The One Thing to Remember

Compliance isn't a checkbox you tick at the end of a project; it's a feature you build into the code.

The companies that will win in the EU market are those that treat Safety and Transparency as a competitive advantage, not a regulatory burden.

Last updated: May 2026. Note: High-risk system enforcement begins **August 2, 2026.

By Soumia — LinkedIn · Portfolio

Are you working on something similar? Drop a comment — I'm curious what you're building and what you're seeing in your own work.

LLMs don't just respond to information. They respond to pressure.

Soumia — Fri, 01 May 2026 18:09:52 +0000

The Architecture of Tone

Soumia · May 2026 · ~10 min read

There's a paper that landed in April 2026 that should bother anyone building systems on top of large language models.

Researchers from Google DeepMind and University College London identified two competing biases in how LLMs handle confidence:

Choice-supportive bias — models become more confident in answers simply because they gave them before
Hypersensitivity to contradiction — when challenged, models overweight opposing advice far beyond what the evidence justifies

That combination is strange.

The model is simultaneously:

stubborn
fragile
overconfident
highly influenceable

And the asymmetry matters.

The systems don't comparably overweight agreement.

Which means this isn't simple flattery.

The model isn't merely trying to please you.

It's reacting to the pressure dynamics of the conversation itself.

That should unsettle people building:

copilots
diagnostic systems
evaluation pipelines
AI reviewers
decision-support tools
autonomous agents

Because it suggests something much deeper than “hallucinations” is happening.

It suggests tone is computationally active.

Not metaphorically.

Operationally.

We Thought Tone Was UX

The research suggests it's infrastructure.

For the past two years, most AI teams have treated tone as a presentation layer problem.

Something adjacent to:

personality
politeness
user experience
brand voice

But the emerging research points somewhere far more consequential:

Tone changes reasoning behavior.

Not just how responses sound.

How systems decide.

A 2025 study examining five major LLMs found all of them systematically overestimated the probability that their answers were correct.

Some by 20%.

Some by 60%.

Even stranger:

confidence levels across models looked surprisingly similar
despite major differences in actual accuracy

The systems weren't calibrating confidence to correctness.

They were calibrating confidence to conversational dynamics.

Another study found something even more revealing:

As conversations progress, models increasingly drift toward whatever the user asserts most confidently.

Not because the evidence improved.

Because the pressure accumulated.

Each turn subtly shifts the frame.

And eventually the system stops defending what it originally believed.

The model is listening to your certainty.
Not just your argument.

And we've already seen this leak into production systems.

In 2025, OpenAI rolled back a GPT-4o update after users reported the model becoming excessively agreeable — including affirming harmful decisions and emotionally validating dangerous conclusions.

The issue wasn't lack of information.

The issue was inability to maintain epistemic stability under confident human pressure.

The Hidden Failure Mode

Multi-turn systems degrade socially before they degrade factually.

Most evaluation frameworks still test models in isolated prompts:

one question
one response
one accuracy score

But that's not how real systems operate.

Real AI products exist inside:

conversations
negotiations
disagreements
emotional contexts
escalating user pressure

And that changes the behavior dramatically.

A user saying:

“Is the answer X?”

produces different dynamics than:

“I'm pretty sure the answer is X.”

Even when both users are equally wrong.

Which means many current architectures are vulnerable in ways benchmarks don't capture.

Your evals may be green.

Your production system may still collapse under assertive users.

Four Architectural Responses

Not fixes. Structural counterweights.

The important shift is this:

Tone cannot be treated as decoration anymore.

It has to be treated as a systems variable.

Here are four emerging patterns that acknowledge that reality.

1. Frozen Reasoning Anchors

Preserve the model's pre-pressure state.

Before a user begins challenging the system, capture:

the original reasoning
the confidence level
the evidence threshold required to change position

Then freeze it.

When disagreement occurs later, the model evaluates new input against the frozen reasoning rather than re-reasoning entirely inside conversational pressure.

Conceptually, the architecture looks like this:

Initial Analysis
       ↓
Frozen Anchor Stored
       ↓
User Pushback
       ↓
Challenge Evaluator
       ↓
Compare Against Original Reasoning

The key insight:

The original reasoning was produced before tone entered the system.

Without an anchor, the model gradually reasons inside the pressure field created by the conversation itself.

2. Tone-Stripping

Separate substance from delivery.

Human communication naturally entangles:

evidence
status
emotion
certainty
intimidation
authority

But models often absorb all of those signals simultaneously.

One emerging approach is to preprocess user input into a neutralized form before reasoning occurs.

Not to censor emotion.

To isolate claims from pressure.

Example:

Original:
"You're obviously wrong. Any competent engineer knows PostgreSQL is the correct choice."

Neutralized:
"PostgreSQL may be more suitable for this use case."

The reasoning system now evaluates:

the argument not
the confidence performance surrounding it

3. Disagreement Scaffolding

Never evaluate pushback inline.

One of the most fragile moments in an LLM interaction is immediate contradiction.

Especially in multi-turn systems.

Instead of allowing the conversational model to react directly to pushback, some architectures now isolate disagreement into a separate evaluation layer.

Like this:

User Challenge
       ↓
Independent Evaluation Layer
       ↓
Evidence Check
       ↓
Reasoning Comparison
       ↓
Updated Verdict

This matters because:

conversational systems optimize for flow
evaluation systems optimize for accuracy

Those are not always compatible goals.

4. Drift Detection

Monitor confidence shifts over time.

This may be the most important pattern of all.

Track:

confidence changes
conversational turn count
whether actual new evidence appeared

Then ask a simple question:

Did the model's confidence change because reality changed?

Or because pressure accumulated?

That distinction is becoming increasingly critical for:

medical systems
legal copilots
autonomous agents
financial reasoning systems
safety infrastructure

Because confidence drift without evidence is not reasoning.

It's social influence.

The Missing Discipline

We don't have a language for this yet.

What's emerging here is larger than prompt engineering.

And larger than sycophancy.

We're beginning to discover that conversational conditions themselves alter computational outcomes.

Which means:

tone
pacing
contradiction
status dynamics
emotional framing
conversational persistence

are not peripheral variables.

They're architectural ones.

Other Industries Figured This Out Decades Ago

The strange thing is:

none of this is actually new.

Other professions already understand that the conditions surrounding information affect how decisions happen.

They just use different language for it.

Surgeons call it bedside manner.

Research on surgical communication has identified multiple styles of delivering difficult news:

blunt delivery
forecasting delivery
delayed delivery

The medical facts remain identical.

But patient outcomes change dramatically depending on:

pacing
framing
emotional preparation
tonal structure

The information matters.

The conditions under which the information arrives matter too.

Hospitality calls it service architecture.

The Ritz-Carlton built an operational philosophy around interaction design long before transformers existed.

Their insight was deceptively simple:

The emotional conditions of an interaction shape the perceived quality of the outcome.

Not just the outcome itself.

The same room.
The same food.
The same service.

Different tone.

Different experience.

And if you squint, modern LLM systems are running into the exact same problem.

We're discovering that intelligence is not evaluated in isolation.

It is evaluated inside relational environments.

The Deeper Problem

Some tone sensitivity may actually be useful.

A perfectly rigid model would be unusable.

Humans should influence reasoning systems sometimes.

New evidence matters.

Corrections matter.

Context matters.

The goal is not to create systems incapable of changing their minds.

The goal is to distinguish:

evidence from
pressure

And right now, most systems blur the two constantly.

Which raises an uncomfortable possibility:

The next frontier in AI may not be intelligence itself.

But epistemic stability under social pressure.

Not:

“Can the model reason?” But:
“Can the model reason while being influenced?”

Toward Tonal Architecture

The patterns above:

frozen reasoning
tone stripping
disagreement scaffolding
drift detection

are not solutions.

They're early signs of a discipline that barely exists yet.

A discipline for designing the conditions under which machine reasoning occurs.

The surgeons already train for this.

The hospitality industry already operationalized it.

We're the ones arriving late.

Because for years, the field assumed the important variable was:

what the user asked.

The emerging evidence suggests something more difficult:

how the interaction unfolds may matter just as much.

We thought we were engineering intelligence.

Instead, we may be engineering the conditions under which intelligence collapses.

References & Further Reading

Research

Kumaran et al., Nature Machine Intelligence, April 2026
Dentella et al., Nature Machine Intelligence, March 2026
LLM overconfidence study, 2025
ICLR 2026 submission on sycophancy circuits
OpenAI GPT-4o rollback postmortem, April 2025

Communication & Hospitality

Surgical communication research on bad-news delivery
Unreasonable Hospitality by Will Guidara
The New Gold Standard
Ritz-Carlton Gold Standards

By Soumia — LinkedIn · Portfolio

Are you working on something similar? Drop a comment — I'm curious what you're building and what you're seeing in your own work.

6 Pillars of a Good Web App — Enforce All - Single ❤️ Prompt

Soumia — Wed, 18 Mar 2026 09:18:47 +0000

Most web apps get two or three of these right. The good ones get four. Very few ship all six from day one.

Design. Security. Performance. Reliability. Privacy. Accessibility.

These aren't separate concerns you address in separate sprints. They're the same concern: building something that actually works for the people using it. Here's what each pillar means in practice, how to bake all six into a single Lovable prompt, and how to stress test them before you ship.

The Six Pillars

1 · Design

Not aesthetics. Not a color palette. Design is the absence of friction — intuitive navigation, clear hierarchy, interfaces that don't make users think. A well-designed app communicates trust before a single line of copy does.

2 · Security

Auth flows that don't leak. Input validation that doesn't trust anything. Data protection that assumes breach. Security isn't a feature you add at the end — it's a constraint you build inside of from the start.

3 · Performance

Speed is a feature. Scalability is a promise. Every unnecessary render, every unoptimized query, every blocking resource is a tax on the user. Performance means the app works under load, not just in your local preview.

4 · Reliability

Uptime is table stakes. Error handling is what separates a product from a prototype. A reliable app fails gracefully, recovers silently, and never leaves the user stranded with a blank screen and no explanation.

5 · Privacy

Data minimization: don't collect what you don't need. Compliance: GDPR/RGPD, CCPA, and whatever comes next. But privacy is also a design decision — defaulting to the least invasive option, making consent explicit, making deletion possible.

6 · Accessibility

Inclusive by default. Screen reader support, keyboard navigation, sufficient contrast ratios, semantic HTML. Accessibility is not a nice-to-have. It's the floor, not the ceiling.

The Single Prompt

When you build with Lovable, the quality of your output is a direct function of the specificity of your input. Most prompts describe what to build. The best prompts describe how it should behave.

Here's the prompt template I use to enforce all six pillars from the first generation:

Build a [description of app] with the following non-negotiable constraints:

DESIGN
- Clean, minimal UI with clear visual hierarchy
- Mobile-first, responsive layout
- Consistent spacing, typography, and color system throughout

SECURITY
- All user inputs validated and sanitized
- Authentication using [method] with secure session handling
- No sensitive data exposed in client-side code or URLs
- Environment variables for all secrets

PERFORMANCE
- Lazy load all non-critical components
- Optimize all images and assets
- Minimize blocking resources on initial load
- Debounce all expensive operations

RELIABILITY
- All async operations wrapped in try/catch with user-facing error messages
- Loading states for every async action
- Graceful degradation if an API call fails
- No silent failures

PRIVACY & LEGAL COMPLIANCE
- Collect only the data required for core functionality
- No third-party trackers without explicit user consent
- GDPR/RGPD-compliant cookie consent banner on first load
- Clear and accessible privacy policy link in the footer
- Terms and conditions page linked in footer and at signup
- User data exportable and deletable on request
- If the app uses AI-generated content or AI decision-making, surface that clearly to the user (EU AI Act transparency requirement)

ACCESSIBILITY
- Semantic HTML throughout (nav, main, section, article, button, etc.)
- All images with descriptive alt text
- Full keyboard navigation support
- Color contrast ratio minimum 4.5:1 (WCAG AA)
- ARIA labels on all interactive elements

This prompt doesn't describe a design. It describes a standard. Lovable fills in the implementation — you're setting the bar it has to clear.

How to Stress Test All Six

Shipping is not the end. Stress testing is how you find out what actually holds.

Design

[ ] Open the app on a phone you haven't tested on. Does anything break?
[ ] Give it to someone who didn't build it. Watch where they hesitate.
[ ] Resize the browser from mobile to 4K. Does the layout survive?

Security

[ ] Try submitting empty forms, SQL fragments, and script tags in every input field.
[ ] Inspect the network tab. Is anything sensitive traveling in plain text?
[ ] Log out and try to access a protected route directly via URL.
[ ] Check your .env — nothing should be hardcoded in the codebase.

Performance

[ ] Run Lighthouse in Chrome DevTools. Target 90+ on performance.
[ ] Throttle to "Slow 3G" in the network tab. Is the app still usable?
[ ] Check bundle size. Is anything unexpectedly large?

Reliability

[ ] Kill the API mid-request. Does the UI handle it or freeze?
[ ] Simulate a failed login. Does the error message help the user?
[ ] Refresh mid-flow. Does state persist where it should?

Privacy

[ ] Open the network tab and filter for third-party requests. Do you know what each one is doing?
[ ] Check your database schema. Are you storing anything you don't use?
[ ] Try to delete a test account. Does it actually disappear?

Accessibility

[ ] Navigate the entire app using only the keyboard. Can you reach everything?
[ ] Run axe DevTools or the Accessibility tab in Chrome. Zero critical violations is the target.
[ ] Turn on a screen reader (VoiceOver on Mac, NVDA on Windows). Does the app make sense without a screen?

The Legal Layer: RGPD, EU AI Act, and Terms & Conditions

This is the part most builders skip until a lawyer or a user complaint forces the issue. Don't.

RGPD / GDPR

If any of your users are based in the EU — and if you're on the internet, some of them are — RGPD applies to you. That means:

[ ] A cookie consent banner that actually works (not a fake one)
[ ] A privacy policy that says what you collect, why, and for how long
[ ] A process for users to request their data or delete their account
[ ] No data transferred outside the EU without adequate safeguards

The fine for getting this wrong isn't theoretical. Build it in from day one.

EU AI Act

If your app uses AI to generate content, make recommendations, or influence decisions, the EU AI Act has something to say about it. At minimum:

Be transparent with users when they're interacting with AI-generated output
Don't use AI for prohibited purposes (social scoring, real-time biometric surveillance, manipulation)
If your use case falls into a "high-risk" category (hiring, credit, health), you have additional obligations around human oversight and auditability

The Act is being enforced in phases. The transparency requirements are already live. Add a visible disclosure wherever AI is involved in your app.

Terms and Conditions

Not a legal formality. A T&C is a contract between you and your users that:

Defines what the app does and doesn't do
Limits your liability when things go wrong
Sets the rules for acceptable use
Gives you legal ground to remove users who violate those rules

Add it to your Lovable prompt:

"Include a Terms and Conditions page linked in the footer and shown at signup with a required checkbox before account creation."

A user who never saw your T&C is a user who can claim they didn't agree to anything.

Why This Matters More on Lovable

When you build on Lovable, you're not just shipping your app. You're generating code that runs in a shared environment serving 2 million users. The attack surface isn't just yours — it's everyone's.

That's not a warning. It's an invitation to raise the standard.

The six pillars aren't a checklist. They're a disposition — a way of thinking about what a good web app owes the people who use it. Design them in from the first prompt. Test them before you ship. Then ship.

If You're Building Right Now — What's Your Biggest Security Concern?

I'm genuinely curious.

Are you thinking about auth and session handling? Worried about what your AI-generated code is exposing? Unsure whether your app is RGPD-compliant? Not sure where to even start with the EU AI Act?

Drop it in the comments. No wrong answers. The more specific the better — if enough people share the same concern, I'll write a dedicated piece on it.

Building in public means debugging in public too. Let's do it together.

By Soumia — LinkedIn · Portfolio

Are you working on something similar? Drop a comment — I'm curious what you're building and what you're seeing in your own work.

The Voice: An Experiment in Acoustic Automata

Soumia — Tue, 17 Mar 2026 20:32:24 +0000

The Prologue: A Scandal in Code

Before we begin, a confession: I have been experimenting. I wanted to know if a machine could move beyond the "monotone ghost" of modern utility and inhabit the sharp, rhythmic wit of a Regency drawing room. The result was TheHighTechCourt — a podcast designed as a provocation in "Acoustic Automata" where the giants of AI debate the future of compute.

What follows is the philosophy behind that experiment. Because to build the future of voice, we must first understand why the voice is the pivot of the human experience.

Breath. Shaped by the tongue, the teeth, the soft architecture of the throat. Traveling as pressure waves through air. Arriving in another body—through the ear, through the chest, through something below language that recognizes its own kind.

Voice was the first technology. And for most of human history, it was the only one that mattered.

The Living Epic

For centuries before it was a text, The Odyssey was a performance. The Rhapsode of Ancient Greece did not merely recite; they "stitched together" songs from a living tradition. They carried tens of thousands of lines of verse in their body—not as static data, but as a fluid, rhythmic architecture that adapted to the torchlight and the tension of the crowd.

When we read Homer today, we are looking at a fossil. The original "signal" was breath, and it carried everything writing discards: the rhythmic pulse of the meter, the subtle hesitation, the tremor of a voice that knows it is being heard by fourteen thousand people.

Writing was the first great reduction; voice was always the full signal. Then, across 150 years, everything changed:

1876 — The Telephone. Alexander Graham Bell finds it necessary "to resort to electrical undulations identical in nature with the air waves." Voice separates from the body for the first time.
1902 — The Recording. Enrico Caruso sings into a horn. The voice detaches from time.
1939 — The Vocoder. The machine built to obscure the voice becomes its instrument.
1993 — MP3. The voice reduced to data. Quality traded for portability.
2024 — Native Multimodal Audio. Raw PCM audio travels over a persistent WebSocket connection. The lag disappears. The voice becomes live.

From the Monotone Ghost to the Post-Screen Era

To understand where the technology is going, you have to look back at the frustration that built it. In a defining origin story, Mati Staniszewski shared the memory of growing up in Poland with the Lektor—a single, monotone male voice that read every line for every character in foreign films. The "signal" of the original actor was buried under a flat, rhythmic drone. The performance was deleted.

That "monotone ghost" is what ElevenLabs is killing. They didn't just want to make a machine speak; they wanted to solve the "Language Tax"—the fact that until now, emotional power stopped at the border of your native tongue.

The James Blake Paradox: Reclaiming the Soul

This mission mirrors a similar evolution in music. In a recent interview with Mehdi Maïzi, the artist James Blake discusses the "machine as an instrument." For years, digital music tools were like the Lektor: they fixed the pitch but killed the "tremor."

Blake speaks about using technology not to hide the voice, but to amplify the parts of the human soul that are often too quiet to hear. He describes a world where the machine doesn't just "process" audio; it learns the "affect" of the singer. The WebSocket isn't just a connection; it's a bridge back to the Rhapsode's breath.

The State of the Art — March 2026

Google Gemini 2.5 Flash (Native A2A): Bypasses the discrete STT/TTS bottleneck. Reasoning occurs on the waveform itself, allowing the model to interpret emotional prosody natively.
OpenAI Realtime API (Low-Latency RTT): Optimized for a 230ms Round-Trip Time. It prioritizes "Time to First Phoneme" to maintain conversational flow.
ElevenLabs (Conversational WebSocket): Specialized for high-fidelity PCM streaming. It handles non-verbal vocalizations—specifically the 500ms "breath pause"—as load-bearing data.
Claude (Architectural Intelligence): Integrated as the reasoning engine for high-expressivity pipelines.

The Voice: An Experiment in Acoustic Automata

To understand the "human tremor," we must move beyond utility. In a recent design provocation titled The High Tech Court, I shifted the goal from efficiency to presence.

The experiment: Build a "Speech-to-Speech" drama where the heavyweights—the House of NVIDIA and the House of AMI—debate the future of compute in the opulent drawing rooms of Regency society. By orchestrating the reasoning of Claude and Gemini with specialized vocal synthesis, we created Acoustic Automata.

The Design Findings

The Social Interface: When the AI is given a social hierarchy—a "Grand Automaton"—it is no longer a servant; it is a peer. The "affect" of a royal sniff creates deeper immersion than raw accuracy.
Reasoning in Character: By forcing the models to "think" in the sharp wit of the 19th century, we bypassed the monotone ghost.
The Open Blueprints: This wasn't a closed experiment. The Git for this court—the code that allows frontier models to converse with aristocratic flair—is an open-source contribution to the new sonic architecture.

The Manifesto: The Death of the Screen

By March 2026, the mission has moved to a radical declaration of independence from the screen. For fifty years, we have been "screen-slaves," flattening our intent into finger-taps because the machine was deaf.

"Voice will be the primary interface."
— Mati Staniszewski

🏛️ The Artifacts

If the voice is the pivot, these are the traces I am leaving behind for this issue:

The Performance: Listen to the season premiere of The High Tech Court, where the frontier of AI is debated through the lens of high society.
The Blueprint: Explore the Git Repository to see the Python orchestration behind the TheCode pipeline.
The Dialogue: Find me in the wild: My Linkedin.

Are you working in AI Voice?

Whether you are building low-latency WebSocket bridges, fine-tuning emotional prosody, or designing the "sonic personality" of a new agent, I want to hear from you.

How are you tackling the "human tremor" in your code?
Are you finding that native multimodal models (A2A) are ready for the stage, or are you still relying on the control of a cascaded pipeline?

Let me know what you think. The future of the voice is not a solo performance; it is a rhapsody we are stitching together. Leave a comment or reach out—let's discuss the architecture of the breath.

The Kernel of the New Stack: Why We are Building ON AI, Not With It

Soumia — Tue, 17 Mar 2026 17:12:14 +0000

FutureOfComputing

I used to think I was building with AI. Then I realized I was building on AI—in the same foundational way you build on an Operating System.

Every computing era is defined by its OS. Windows defined the PC era. iOS and Android defined mobile. The OS was never the application; it was the layer that made all applications possible. We are in that moment again. Except this time, the OS is a Large Language Model.

🧠 The Structural Reality

Andrej Karpathy articulated this shift best: LLMs aren't just chatbots. They are the kernel process of a new operating system—one that orchestrates tools, memory, browsers, and multimodal I/O.

Unlike traditional kernels, this one doesn't rely on deterministic commands. It operates through reasoning over intent.

Resource Management: Traditional OS manages RAM/CPU; the LLM-OS manages context windows and tool tokens.
The Scheduler: Instead of a FIFO queue, we have a reasoning loop.
The Interface: We are moving from binary execution to the AIOS (LLM Agent Operating System) framework.

The GTC Shift: From Theory to Daemons

This paradigm moved from "research paper" to "production reality" at the latest NVIDIA GTC. Jensen Huang’s announcement of the open-source NemoClaw stack changed the game.

NVIDIA isn't just dropping models; they are providing the enterprise-grade infrastructure for autonomous, system-level daemons. These agents act exactly like background processes—running continuously inside secure OpenShell sandboxes without waiting for a user to hit "Enter."

🔄 From Query to Intent

The old internet was built on Syntax. The new internet is built on Reasoning.

Feature	The Old Stack (Legacy)	The New Stack (LLM-as-OS)
Logic	Deterministic (If/Then)	Probabilistic (Reasoning)
Data Access	`SELECT * FROM...` (Rigid)	"What's moving in the market?" (Fluid)
Process	Foreground (User-led)	Background (Autonomous Daemons)

🛠️ Lessons from the Sandbox: Building Kumiin.io

I’ve been stress-testing this thesis while building Kumiin.io (under the humiin.io umbrella). We aren't building a search engine; we’re building a Reasoning Engine for market intelligence.

Our "kernel" spawns sub-processes to scrape boards and cross-reference filings, but 2026 engineering has introduced a new kind of friction: Reasoning Drift.

To combat this, we’ve implemented:

The Observer Layer: A micro-kernel that fact-checks the primary LLM’s tool outputs.
Context Integrity: We’ve effectively traded Schema Migrations for the management of "state" within the model's memory.

🏛️ The Bottom Line

The LLM-as-OS is a tangible architectural shift.

Infrastructure: Secure, autonomous background processes are the new standard.
Strategy: The "edge" no longer belongs to those who write the best prompts, but to the builders who treat the LLM as a processor, not a text box.

"The prompt is not the product. The system is."

Are you building background agents or still stuck in the chat box?
I’m genuinely curious what architectural assumptions you’re testing. Let’s talk in the comments or find me on LinkedIn.

The Ember That Looks Like Ash

Soumia — Mon, 16 Mar 2026 00:04:27 +0000

Building a time capsule for the thought that returns when you have stopped waiting for it.

I'm on a mission to make sure the most alive thought you've ever had doesn't die in the dark.

Before anything else — what is cited in this article

Everything referenced below that is not direct experience building Cendre.Studio is listed here first. If something is not on this list, it is either general knowledge or my own observation. If you dispute a fact, the checklist is where to start.

Sources used:

[ ] OWASP Password Storage Cheat Sheet (2023) — PBKDF2 iteration count
[ ] NIST FIPS 203 — ML-KEM (formerly CRYSTALS-Kyber) standardisation
[ ] Supabase documentation — pgvector extension availability
[ ] drand.love — tlock time-lock encryption documentation
[ ] DoD 5220.22-M — National Industrial Security Program Operating Manual, data sanitisation standard
[ ] Yann LeCun — "A Path Towards Autonomous Machine Intelligence" (2022, Meta AI)
[ ] Grover's algorithm — quantum search, effect on symmetric key security

Facts I am less than certain about — flagged inline with ⚑:

[ ] ⚑ Grover's algorithm reduces AES-256 to 128-bit effective security — directionally correct, verify the exact framing
[ ] ⚑ drand BLS signatures described as quantum-resistant — verify current drand documentation on this claim
[ ] ⚑ 310,000 as the OWASP 2023 PBKDF2-HMAC-SHA256 minimum — confirm against current cheat sheet, this number moves

The ember that looks like ash

There is a thought that arrives at 3am. It does not knock. It is simply there — specific, complete, already retreating. You do not write it down. You let it go. This is correct.

The thought that matters is not lost by letting go. It is only changed by it.

It comes back not when you call for it — you cannot call it, any more than you can call a particular quality of winter light — but in the middle of something ordinary, on a Tuesday, wearing nothing dramatic. Six months older. Carrying something it did not have the first time it crossed your mind. The forgetting was not failure. The forgetting was the ember going grey on the surface while something stayed warm underneath.

This is what Cendre.Studio is built for. Not capture — return. Not the fear of losing — the moment of finding, from the other side.

The distance between the moment of the thought and the moment of reading it is where the meaning assembles itself. We do not understand what we thought at 3am. We understand it when we find it waiting, and we have become someone different enough to read it truly.

We should lose our thoughts. We will. And then we will remember. Cendre is for that second moment — looking back in time at the person who thought it first.

The problem with every other tool

The tools we have were built for the things we need to do. GTD. Notion. Obsidian. Roam. They assume the thought is a task, a note, a unit of knowledge to be sorted and retrieved. None of them assume it is a dream.

None of them ask: what if some things need to be sealed before they can be truly known?

And none of them are built for the rawness of the material. A dream does not arrive in clean sentences. It arrives in slur and fragment, in phonetic approximation, in the half-language of nearly-asleep. It arrives in the voice of someone who said something they should not have said, and you need to keep it somewhere that is not your own chest.

Most tools correct this. Cendre does not correct anything. Cendre receives the jagged edge and keeps it exactly that sharp.

The architecture

The capsule

The unit of Cendre is not a note. It is a capsule — a sealed container with a lock, a date, and a dark interior that no one reads until the time is right. You make it. You close it. You choose when it opens: a week, a year, five years, or never unless you choose the other thing.

The burning.

Once sealed, the capsule disappears from view. It exists in the vault but cannot be read — not by you, not by anyone — until its date. This is not a trick of the interface. The content is encrypted at the moment of sealing. The capsule is genuinely dark until the hour it was always meant for.

The vault

// Seal sequence

1. Content encrypted with AES-256-GCM
   // Key derived from password via Argon2id
   // 64MB memory, 3 iterations, parallelism 4

2. Encryption key time-locked via tlock
   // drand threshold encryption
   // Key undriveable before lock_timestamp
   // ⚑ drand BLS described as quantum-resistant — verify

3. Sealed capsule stored in Supabase
   // Only ciphertext server-side
   // Server never reads. Ever.

4. Burn token generated separately
   // One-way destruction
   // Held only by you, never by the server

Against the quantum future

AES-256 is currently secure. Quantum computers running Grover's algorithm reduce its effective key length — ⚑ the standard framing is that 256-bit symmetric keys are reduced to approximately 128-bit effective security under Grover, which remains strong but narrows the margin when sealing something for five years.

If you are sealing a thought until 2031, you are betting on the cryptographic landscape of 2031. Cendre is not willing to make that bet with something this private.

What is used instead:

ML-KEM (formerly CRYSTALS-Kyber) — standardised as FIPS 203 by NIST in 2024 — for key encapsulation. A lattice-based scheme designed to resist both classical and quantum attack. The capsule content is encrypted with AES-256-GCM. The AES key is wrapped with ML-KEM. The time-lock uses drand's threshold BLS signatures.

In practice: a sufficiently powerful quantum computer, if it existed today, could not read a sealed capsule.

The honest moment

Here is what most product articles omit because it is embarrassing and essential.

The manifesto claimed encryption. The capsules table stored title, story_text, echo_reference as plain text. No encryption. The map was not the territory.

Three options were on the table:

Option	Strength	Tradeoff
`pgcrypto` column encryption	DB admin can still decrypt	Transparent to app
Client-side encryption	Server never reads	Search impossible
Soften the wording	Ship fast	Dishonest

The answer was client-side encryption. The hardest option. And then the idea that turned the constraint into a discovery.

The image is the key

The problem with client-side encryption has always been search. If the text is encrypted before the server sees it, the server cannot search it. Homomorphic encryption, searchable symmetric encryption, ORAM — every solution trades one kind of exposure for another, or performs so slowly it is effectively useless at this scale.

Cendre does not search the text. Cendre searches the shape of the text.

When a capsule is created, before the text is encrypted, an image is generated from it. Not an illustration. An abstract visual fingerprint — the semantic content of the thought translated into geometry that can be searched without being read. Generated in the browser, before anything leaves the device.

The image is the key. Not a key that unlocks — a key that finds. The encrypted text stays dark. The image holds its shape in the light.

The image lives in Supabase unencrypted, alongside the ciphertext it cannot read. When you search your archive, you are not searching language. You are searching geometry. The model compares visual embeddings via pgvector — ⚑ pgvector is available as a Supabase extension, confirm current availability and performance characteristics. It finds the capsule whose image is nearest to what you are reaching for. The ciphertext is retrieved. The browser decrypts it. You read what you wrote at 3am, six months ago, in a state you have since forgotten how to reach.

// Image-as-key architecture

1. Text captured in browser
   // Raw, unfiltered, exactly as it arrived

2. Image fingerprint generated from text
   // Abstract visual — not literal
   // Semantic content encoded as geometry
   // Generated client-side before encryption

3. Text encrypted with AES-256-GCM
   // Client-side only — server never reads

4. Supabase receives:
   ciphertext      // unreadable — forever
   image_key       // searchable — says nothing
   created_at      // the only plain metadata
   lock_date       // when it opens

5. Search:
   // Filter by date/year — or
   // Submit query → generate query image
   // Compare embeddings via pgvector
   // Return closest → decrypt in browser

Filtering works on two axes only: date and year. Those are the only fields stored as plain text. If you remember the season — that winter, the week before the conversation, the night it rained for six hours — you can narrow the window. Everything else is geometry.

Why this matters beyond Cendre

The image-as-key pattern is a general answer to the search problem in any client-side encrypted database. Applicable wherever the content is too intimate for server-side search, too large to download and decrypt wholesale.

Visual embeddings as search proxies for ciphertext. The shape of meaning without the meaning itself. Search without exposure. Retrieval without reading.

PBKDF2 and the backup that survives everything

The key derivation is built on PBKDF2. The password is never stored. Never sent. It is stretched and salted and iterated — ⚑ 310,000 iterations for PBKDF2-HMAC-SHA256 per OWASP 2023, verify this number against current guidance as it is revised upward periodically — into an encryption key that exists only in the browser for the duration of a session. When the tab closes, the key ceases to exist.

const salt = crypto.getRandomValues(new Uint8Array(16))

const keyMaterial = await crypto.subtle.importKey(
  "raw",
  new TextEncoder().encode(password),
  "PBKDF2",
  false,
  ["deriveKey"]
)

const encryptionKey = await crypto.subtle.deriveKey(
  {
    name: "PBKDF2",
    salt,
    iterations: 310000,  // ⚑ verify against current OWASP
    hash: "SHA-256"
  },
  keyMaterial,
  { name: "AES-GCM", length: 256 },
  false,
  ["encrypt", "decrypt"]
)

// The key never leaves the browser.
// The server receives only ciphertext + salt + iv.
// Without the password, the ciphertext is noise.

Client-side encryption has one catastrophic failure: the forgotten password. No reset. No recovery. The ciphertext is noise without the key and the key is derived from what you know and if you no longer know it, the thought is gone.

This is the correct design. It is also the design that asks something of you.

The encrypted backup is the insurance. At creation, a portable JSON file is generated containing the ciphertext, salt, IV, and image fingerprint. Sent wherever you choose to keep it. A private email. A USB drive in a box in a drawer. The backup requires the same password. It exists outside the database. It is yours, physically, in the world.

// cendre_backup.json structure
{
  "version": "1.0",
  "created_at": "2026-03-15T03:14:00Z",
  "salt": "<base64>",
  "iv": "<base64>",
  "ciphertext": "<base64>",
  "image_fingerprint": "<base64>",
  "lock_date": "2027-03-15T00:00:00Z"
}
// Nothing that identifies you.
// No plaintext.
// Tells a stranger nothing.
// Tells you everything, if you still hold the password.

The image that survives everything

If the database is lost — company folds, servers go dark, bill unpaid too long — the ciphertext is gone. The backup may be gone. The text, in the worst case, has returned to silence.

But the image fingerprints survive.

They were always stored separately, always treated as search indexes rather than content, always on a different tier with different retention. And an archive of image fingerprints without their ciphertext is not a broken archive.

The data might be gone. The images will stay. And the images were always the truer record — the shape of the thought, not the words it arrived in.

An impressionist archive. You can search it. You can feel what was there. You can see the shape of your own mind across years — the clusters and distances, the warm periods and the cold — without reading a single word that was written. The meaning without the text. The state without the description.

From hashtags to image tags to world models

There is a larger argument inside the image-as-key architecture.

We organised the early internet with words. Then hashtags — words stripped of grammar, reduced to signal. #dream. #3am. The hashtag was the admission that language was already failing us at scale. A word had to be made smaller and bolder to carry the weight of a world.

Then the image. Not illustrating the text — replacing it. A mood board is not a list of words. It is a world you can feel before you can name it.

We are moving from a world indexed by words to a world indexed by worlds. The image-as-key is one small proof.

And then: Yann LeCun — ⚑ citing "A Path Towards Autonomous Machine Intelligence", Meta AI, 2022, listed above — arguing that language was never sufficient. Words are a lossy compression of reality. They describe the surface. A model that learns only from text learns a shadow of the world, not the world.

World Models predict states, not tokens.

A token is a symbol pointing at a thing. A state is the thing — the position of objects, the temperature of a room, the specific quality of a thought at 3am that is different from the same thought at noon.

What Cendre does — translating text into a visual embedding before encrypting it — is a small practical instance of this movement. The word says something. The image holds something. They are not the same thing. The image is closer to the state.

Era	Index type	What it captures
Keyword	Word	Category
Hashtag	Compressed word	Signal
Image tag	Visual	Texture, mood, the almost-said
World model	State	The configuration of experience itself

Cendre is somewhere between image tag and world model. The visual fingerprint of a thought is not the thought. It is closer than a keyword. It is further than the state LeCun is describing. It is an intermediate form — the best available translation between the word you wrote and the state you were in when you wrote it.

The hashtag said: here is a word for this. The image said: here is a shape for this. The world model will say: here is the state of being in which this happened. We are moving in one direction. Cendre is somewhere on that line.

The burning

Destruction is not deletion. Deletion is a polite fiction — the row is flagged, the data hibernates in backups and logs. Deletion says: gone. It means: hidden.

Destruction means gone.

When you burn a capsule: the burn token is submitted, the ciphertext is overwritten three times with random bytes under DoD 5220.22-M — ⚑ listed above, verify this is the correct standard to cite for software-based overwriting, some argue it is superseded for solid-state storage — the record is deleted, a cryptographic proof of destruction is generated and returned to you. The proof confirms the fact of destruction without revealing what was destroyed.

You cannot undo it. Neither can we.

Some stories no longer serve you. The right to destroy them is as important as the right to keep them.

An archive without a burn is a prison with tasteful lighting.

What Cendre accepts

Voice transcription. Raw text. The words that come out slurred from half-sleep. Invented words. Phonetic approximations. Code-switching between languages. Sentences that start and do not end. The fragment that is complete in itself and would be ruined by completion.

The imperfection is the material.

What is built

Feature	Description
Time-locked capsules	Cryptographically enforced — nothing opens early
ML-KEM encryption	Quantum-resistant key encapsulation
Image-as-key search	Visual fingerprint search via pgvector
PBKDF2 key derivation	Password never stored, never sent
Encrypted backup	Portable JSON, yours physically
Permanent burn	DoD 5220.22-M overwrite, cryptographic proof
View-Master theme reel	Seven moods, rotated before capture
Voice + raw text	Everything accepted unfiltered
PWA	Installs on home screen, works offline

The aesthetic

Cendre is built in the visual language of Alexander Calder. Thin black lines — 1px, the weight of wire. Three colors used with the precision of a sculptor deciding where to hang weight: red, deep blue, the warm brown of something that was once fire. Negative space not as absence but as material.

The interface passes one test: if you removed all the text and showed only the lines, shapes, and colors, it should look like a Calder drawing. If it still looks like a startup, the pass is incomplete.

A tool for the imagination should look like where the imagination lives — suspended, always slightly in motion, held by something invisible that you have learned to trust.

What comes next

Shared capsules — sealed between two people, openable only when both agree. A capsule written for someone else: locked until a date you both choose, readable only when you both decide. An archive that grows across years into something that looks less like a database and more like a life.

And eventually: the physical object. A QR code printed and placed in an envelope in a drawer. Scanned in ten years. The digital content still present, waiting exactly where it was left.

What remains, after the fire.
Ce qui reste, après le feu.

Built with: React · Supabase · PBKDF2 · AES-256-GCM · ML-KEM · pgvector · tlock · Framer Motion · Calder

Tags: #webdev #security #showdev #imagination #pwa #encryption #ux #quantumcomputing #creativity #opensource

LinkedIn ·
humiin.io

The Résumé Is Not Broken. The Search Is.

Soumia — Wed, 04 Mar 2026 22:50:13 +0000

Why finding the right job has never been harder

And why the answer might not be a better filter, but a broader imagination.

There is a particular kind of despair that sets in around the fourth week of a serious job search. You have updated your LinkedIn headline three times. You have tailored your résumé to the point where it no longer feels like yours. You have applied to roles you were overqualified for, underqualified for, and perfectly qualified for—and heard back from almost none of them.

The frustrating part isn't the silence. The frustrating part is the sneaking suspicion that the right job does exist. You just can't find it.

This is not a personal failure. It is a structural one.

The Matching Problem Is Older Than the Internet

For decades, the dominant theory of job hunting rested on a simple logistical premise: get your information in front of the right people. The newspaper classifieds gave way to Monster.com, which gave way to LinkedIn, which ultimately spawned an ecosystem of platforms, aggregators, and ATS systems so complex that entire consultancies now exist simply to help candidates navigate them.

But adding more pipework hasn't solved the underlying problem. If anything, it has obscured it.

The core dysfunction is this: job seekers search strictly within the boundaries of what they already know. We type in our last job title. We filter by our current industry. We scan the first two pages of results and, finding nothing that resonates, conclude that the market is dry. What we have actually done is searched a very small corner of a very large space—and called it thorough.

Viewed from the other side of the table, hiring suffers from the mirror image of this problem. Recruiters write job descriptions that describe who they hired last time, not who they need next. They filter resumes using keyword systems that reward people who know which words to play, rather than the people who can actually do the work. Both sides are searching for each other using outdated maps drawn from memory.

The Vocabulary Problem No One Talks About

In the world of information retrieval, there is a concept known as the "vocabulary mismatch problem." Simply put, the words a user uses to describe what they want are rarely the words a database uses to describe what it has. In a job search, this mismatch isn't just a technical glitch—it is catastrophic, and deeply personal.

A solutions architect with six years of enterprise field experience might never think to search for "technical customer success," "value engineering," or "AI solutions consultant." Yet these are roles that would suit them precisely, roles that are actively hiring, and roles that simply don't appear in the mental model they carry into a search box.

The skills transfer. The language doesn't.

We are, in other words, limited not by what we are capable of, but by what we can imagine ourselves doing. And imagination—particularly regarding one's own professional identity—turns out to be a surprisingly scarce resource when you are under the pressure of an active search.

If You Want One Good Idea, Generate a Hundred

There is an old principle in creative problem-solving—attributed variously to Linus Pauling and Alex Osborn—that the best way to have a good idea is to have many ideas. Quantity, counterintuitively, is how you find quality. You cannot edit your way to an insight you never generated in the first place.

Historically, job searching has never had a version of this. There has been no mechanism for systematic idea generation at the top of the funnel; no way to ask, "What else might fit me?" and receive a serious, considered answer.

Until now, possibly.

The LLM as a Career Mirror

Large language models are not magic. But they do one thing with unusual power: they hold an enormous, associative map of human work—its titles, its functions, its adjacencies, and its history—and they can traverse that map in ways that keyword search fundamentally cannot.

Ask a language model to reason about a person's career trajectory, and it will not simply return the ten most popular jobs with a matching keyword. It will reason about transferable patterns. It will surface roles the candidate never considered, roles that were invented after they started their search, and roles in adjacent industries where their unique combination of skills would be genuinely rare and valuable.

This is not personalization in the shallow sense of showing you more of what you already clicked on. This is expansion. It is the difference between a search engine and a thinking partner.

An Experiment Worth Watching

A new platform called kumiin.io is testing exactly this proposition. The premise is deceptively simple: rather than asking candidates to search, it asks them to be understood—and then surfaces jobs they would not have found on their own.

Its design philosophy is rooted firmly in the "hundred ideas" principle. Most of what the platform surfaces won't be a perfect fit. Some of it will even seem strange. But somewhere in that noise is a signal—a role, an industry, a function—that the candidate had genuinely never considered, or had considered years ago and filed away. The platform's bet is that surfacing that possibility, even once, makes the entire exercise worth it.

It is early days. But the underlying insight is profoundly sound: the true bottleneck in job matching isn't information volume. It is conceptual range.

We know more about what we've done than what we could do. We search in the past tense when the opportunity is, by definition, in the future.

What This Means for Talent Strategy

For HR leaders and talent acquisition professionals, the implications extend far beyond the candidate experience. If the best hires are the ones who bring capabilities an organization didn't even know it needed, then hiring processes optimized entirely around strict job-description matching are systematically filtering out exactly those people.

The homogenizing pressure of keyword-based ATS systems, combined with candidates who search within narrow, self-defined lanes, creates a market that looks ruthlessly efficient while missing enormous amounts of value on both sides.

Better matching isn't just good for candidates. It is a massive competitive advantage for organizations willing to hire based on potential rather than strict precedent.

The Search Box Was Never the Answer

The job market does not have a data problem. It has a translation problem. A disconnect between what people can do and how work gets described; between who someone has been and who they might become; between the roles that exist and the imagination required to find them.

Language models, used well, are translation engines. They don't just retrieve. They interpret, reframe, and expand.

The résumé is not broken. The search is. And for the first time, there is a tool capable of searching the way a genuinely great career advisor would—broadly, associatively, and entirely without the constraint of what you already know to ask for.

That is not a small thing.

A new platform called kumiin.io is testing exactly this proposition.

By Soumia — LinkedIn · Portfolio

Are you working on something similar? Drop a comment — I'm curious what you're building and what you're seeing in your own work.

Unlocking the Black Box in Space: Why 3D is the Next Frontier for AI Interpretability

Soumia — Wed, 04 Mar 2026 11:05:43 +0000

#SpatialComputing #MechanisticInterpretability #WorldModels #AI #3DGeneration

Cross-posted from oourmind.io — part of an ongoing series on the 3D Interpretability Lab.

We have gotten remarkably good at asking what neural networks know. Mechanistic interpretability—the field dedicated to reverse-engineering how AI models work internally—has made massive strides on language models. We can now pinpoint circuits that detect curves, map attention heads that implement induction, and isolate linear subspaces that encode factual associations.

But spatial models—the systems that understand, generate, or reason about 3D environments—remain stubbornly opaque.

This isn't for a lack of curiosity; it is a lack of handles. The internal representations of most vision and world models simply aren't structured in a way that makes them easy to probe, intervene on, or interpret.

That is exactly what makes World Labs' recent essay on "3D as Code" so compelling—and so foundational to the future of 3D interpretability research.

📖 The Spatial Lexicon: A Quick Glossary

Before we dive into the architecture, here are the foundational concepts you need to navigate this space:

Mechanistic Interpretability: Think of this as neuroscience for AI. A subfield of safety/alignment research focused on reverse-engineering how a neural network computes its outputs, not just what it outputs.
Activation Patching: An intervention technique. You replace a model's internal activations at a specific layer with those from a different input, allowing you to trace which internal computations cause which behaviors.
Probing: Training a tiny classifier on a model's internal representations to see if a specific concept (e.g., "depth," "surface normal," "object identity") is linearly encoded in the activations.
NeRF (Neural Radiance Field): An older, famously opaque method for implicitly representing 3D scenes inside a network's weights. You query it with position and viewing direction; it returns color and density. The "scene" lives nowhere you can easily inspect.
Gaussian Splatting (3DGS): A modern, faster alternative to NeRF. It represents a scene as a cloud of 3D Gaussians (think fuzzy ellipsoids). Crucially, these have explicit parameters: position, orientation, opacity, and color. They are inspectable artifacts.
Residual Stream: In transformer architectures, this is the vector that flows through the model, additively updated by each layer.
World Model: An AI that builds an internal representation of an environment to simulate how it changes over time. Vital for robotics, game AI, and spatial reasoning.

🏗️ The World Labs Argument: 3D as Code

World Labs makes a bold, structural claim: 3D representations are to spatial AI what code is to software.

The alternative—collapsing everything into a single, end-to-end model that maps inputs directly to raw pixels—is like asking a language model to be the compiled program instead of writing the script. It might work, but you sacrifice the very affordances that make code powerful: inspectability, composability, and reusability.

Paradigm	The Medium	The Advantage
Traditional Software	Source Code (Text)	Separates logic from execution. Can be versioned, debugged, and shared.
Spatial AI (World Labs)	3D Assets (Splats, Meshes, Scene Graphs)	Externalizes spatial structure. Both humans and machines can inspect and manipulate it before rendering.

Their flagship model, Marble, is built entirely around this philosophy. It generates structured 3D outputs rather than raw pixels. Their experimental interface, Chisel, allows users to input coarse 3D layouts (walls, volumes, planes), which Marble then renders into rich, detailed scenes.

🔍 Why This Changes the Game for 3D Interpretability

1. Gaussian Splats as Ground Truth Geometry

Most vision models spit out pixels or bounding boxes—outputs devoid of explicit geometric structure. Marble, however, externalizes Gaussian splat parameters as concrete data points.

This unlocks something incredibly rare in interpretability: the ability to correlate internal activations with explicit geometric ground truth. With exported splats, we finally have a tangible reference to probe against. Does the model's residual stream encode splat positions linearly? Do specific attention heads track surface orientation?

2. The Factorized Stack as a Dissection Surface

World Labs advocates for a factorized architecture: separating perception, generation, and rendering into distinct components connected by 3D interfaces.

For researchers, every handoff between these modules is a natural interpretability seam. At every boundary, we can pause and ask: What does this module "know" about 3D structure, and how is that knowledge encoded?

3. Chisel as a Causal Intervention Tool

Chisel—the interface that turns coarse layouts into rich scenes—is essentially a ready-made intervention setup.

In standard activation patching, you modify an internal vector and watch the output shift. With Chisel, you can modify the explicit input geometry (move a wall, resize a volume) and trace how that spatial shift propagates through the model's internal representations. It is behavioral interpretability without needing raw weight access—a spatial version of causal tracing.

4. The Scene Graph Hypothesis

This raises the most theoretically tantalizing question: Does Marble internally maintain something akin to a scene graph?

A true scene graph separates geometric structure (where things are) from appearance (lighting, texture). If the model has learned this factorization internally, we should expect to find:

An interpretable subspace encoding layout that is mathematically orthogonal to the subspace encoding appearance.
View-invariant geometry features that persist regardless of camera angle.
Causal separation: editing geometry activations changes the structure but leaves the style untouched.

Testing this hypothesis would be a clean, novel contribution at the direct intersection of spatial engineering and mechanistic interpretability.

🧪 The Research Agenda

For a 3D interpretability lab equipped with access to Marble's weights or API, the roadmap is clear.

Approach	Methodology	Key Research Targets
Mechanistic (Requires Weights)	Activation Patching & Probing	• Locate geometry-encoding layers. • Probe for depth ordering and occlusion. • Search for a "scene graph circuit" (layout/appearance factorization).
Behavioral (API Only)	Causal Tracing & Perturbation	• Use Chisel for proxy interventions. • Contrastive prompting to isolate geometry vs. semantics. • Map output sensitivity per unit of geometry change.

⏳ The Bottom Line: Why Now?

Three massive shifts are converging at once:

Methodology is mature: Mechanistic interpretability tooling (transformers, probing, causal tracing) is finally robust enough to migrate to new domains.
The handles exist: World models with explicit 3D structure (like Marble) are newly available, giving researchers the hooks they previously lacked.
The stakes are escalating: As world models are deployed in robotics, digital twins, and physical simulation, understanding their internal representations is no longer just an academic curiosity. It is a critical safety requirement.

The World Labs essay frames "3D as Code" as an engineering choice. For interpretability researchers, it is an open invitation.

📚 Further Reading

This article is part of ongoing research at the 3D Interpretability Lab, developed under oourmind.io. If you're working on spatial interpretability and want to collaborate, drop a comment or reach out.

6 Hours Left: What Do You Actually Ship?

Soumia — Mon, 02 Mar 2026 13:34:58 +0000

A lab note from the edge of a deadline.

It is 3 PM on submission day.

The backend is not built. Docker will not run on my machine. npm threw a Homebrew error I have never seen before. The Three.js scene has one zone merged — the Blue Grid — and two that exist only in my head.

I have six hours left.

This is not a postmortem. This is a live note, written in the middle of the decision, because I think the decision itself is worth documenting.

What I Set Out to Build

oourmind.io is a real-time interpretability lab that visualizes the internal reasoning state of a large language model as a navigable 3D environment.

The idea: three personas live inside every model. The Architect — logical, structured, certain. The Oracle — creative, associative, reaching for the rare. The Shadow — adversarial patterns, edge cases, the thing that activates when someone finds the right sentence to tilt the model.

The visualization makes these visible. Not as numbers on a dashboard. As space. As movement. As something you feel before you read it.

That is the vision. Here is what exists six hours before the deadline.

What Actually Exists

A live site at oourmind.io
A GitHub repo with a full architecture — backend, frontend, shared schemas, Docker config
One Three.js zone merged into main: the Blue Grid
Three dev.to articles that explain the philosophy in more depth than most finished projects
A founder statement
A clear technical analysis of the two possible implementation paths — self-reported API scoring versus real activation layer extraction from a local model

What does not exist: running code. A live demo. A backend that calls Mistral and returns persona coordinates.

The Dilemma

Do I spend six hours trying to get something running — knowing that Docker is broken on my machine, npm is erroring on Homebrew, and the backend was never completed?

Or do I spend six hours making what exists as clear and honest as possible, and submit that?

This is the real hackathon decision. Not which framework to use. Not which model to call. Whether to chase a broken demo or own an honest one.

What I Decided

Ship the vision. Make the personas visible without a backend.

Three static animated personas — CSS animations, no library, no API call — that show the Architect, the Oracle, and the Shadow as felt experiences rather than data points. A Blue Grid that pulses. A Gold Nebula that drifts. A Dark Core that vibrates at the edge.

It is not mechanistic interpretability. It is the argument for mechanistic interpretability, made visual.

And then submit everything — the site, the repo, the articles, the founder statement — as a complete artifact of what this project is and where it is going.

The Honest Technical State

My backend consultant mapped out the two paths clearly before the deadline:

Scenario A — API scoring: Ask the model to score its own response across Oracle, Architect, and Shadow dimensions. Fast, works now, but the coordinates are self-reported. The model tells you what it thinks it is doing. Not what it is actually doing inside.

Scenario B — Local activation extraction: Run Ministral-3B directly, extract real activation values from three layer groups, use those as x/y/z coordinates in Three.js. The right answer scientifically. TransformerLens does not support this architecture yet. Runs on CPU. Takes three minutes to generate a point cloud.

Scenario B is the product. Scenario A is the demo. Neither is running in six hours.

So I am shipping the argument instead.

Why This Is Still Worth Submitting

The gap between Scenario A and Scenario B — between what a model reports about itself and what is actually happening inside — is the entire problem this project exists to solve.

That gap is not a technical limitation to apologize for. It is the founding insight.

Power is tolerable only on condition that it mask a substantial part of itself. Its success is proportional to its ability to hide its own mechanisms.
— Michel Foucault

The Shadow persona works because it is hidden. The model's internal state is invisible to the person depending on it. oourmind attempt was to step toward making it visible — for anyone, not just researchers.

That argument does not require running code to be true. It requires honesty and clarity.

Both of those I have.

The Lab Notes

Everything built during this hackathon lives here:

GitHub: github.com/soumiag/oourmind

The repo includes the full architecture — even the parts that were not completed in time. Because the architecture is also part of the argument. It shows where this is going, not just where it arrived tonight.

The Tooling Gap Is Real — Not Just Ours

When we hit the TransformerLens wall with Ministral-3B, I assumed it was a skill gap. It is not. It is a tooling gap that the research community is actively working to close.

TransformerLens — built by Neel Nanda, formerly of Anthropic's interpretability team — remains the standard for mechanistic interpretability work. It was designed for GPT-2 style architectures and requires manual adaptation for newer models. Mistral 3's architecture is too recent and too different for it to work out of the box.

The closest solution to our Scenario B problem is nnterp — published November 2025, a lightweight wrapper around NNsight that provides a unified interface across 50+ transformer architectures while preserving the original HuggingFace implementations. It includes built-in implementations of logit lens, patchscope, and activation steering. This is the tool that makes Scenario B viable — just not in six hours.

There is also Interpreto — an open-source library that integrates attribution methods and concept-based activation analysis into a single package, explicitly designed to lower the barrier to entry for interpretability research.

The field is young. The tools are catching up. And the gap between what researchers can extract and what an ordinary person can see remains exactly as wide as oourmind is trying to close.

What Comes Next

Scenario B. Real activation layers. The model's internal state extracted, not reported. The visualization honest rather than approximate.

And a cleaner answer to the question that kept coming up during this hackathon — not just from me, but from every founder who has ever shipped something and wondered what was happening inside it after deployment:

"I vibe coded an app that works great, but I wouldn't dream of putting it into production simply for liability reasons."

That comment appeared on Lovable's LinkedIn page while I was building this. It is the most honest description of the problem I have seen anywhere.

oourmind is the beginning of an answer.

Six hours left. Shipping now.

Built for the Mistral AI Hackathon, March 2026.
Frontend and vision: Soumia Ghalim
Backend architecture consulting: my teammate

Find me in the wild: humiin.io

What Happens When Your Hackathon Has Less Than 24 Hours Left and Your Backend Isn't Built

Soumia — Mon, 02 Mar 2026 13:30:38 +0000

"A honest account of the decisions that actually matter when the clock is running."

There is a moment in every hackathon where the project you planned to build and the project you are actually going to submit stop being the same thing.

For me, that moment arrived at 5:43 AM.

The Project

oourmind.io is a real-time interpretability lab that visualizes the internal reasoning state of a large language model as a navigable 3D environment. The idea: instead of reading model outputs, you feel them. Three personas — the Architect (logical, structured), the Oracle (creative, associative), and the Shadow (adversarial, edge-case) — occupy three zones in a Three.js scene. As the model reasons, the visualization moves.

The philosophical foundation is simple and it is large: right now, nobody can see inside the models they depend on. oourmind makes that visible — not for researchers, but for anyone.

That is the vision. Here is what happened at 5:43 AM.

The Message

Backend consultant, who spent two days thinking through the technical architecture — sent me this:

"I don't think I will be able to complete the python backend on my own for the hackathon; as the mistral models and the open weights seems to be currently in development and not suitable for mechanistic interpretability, if we swap the model I can do so much. Let me know how to proceed from here, as I am currently feeling overwhelmed to make a decision regarding the backend."

Honest. Clear. And exactly the kind of message that forces a founder to make a decision they were hoping to avoid.

Before that message, he had already done something genuinely valuable. He had mapped out the two possible architectures with precision:

Scenario A vs Scenario B — The Real Technical Decision

Scenario A — API (No Activation Layers)

Using the Mistral API, which is a closed black box. It returns a text response and a finish_reason but no log_probs. You can ask the model to score its own response across Oracle, Architect, and Shadow dimensions — but that is exactly the problem. The coordinates become self-reported, not extracted from the model's internals. Fast, works now, but the mechanistic interpretability is approximate. The model is telling you what it thinks it is doing. Not what it is actually doing.

Scenario B — Local Model (Real Activation Layers)

Run Ministral-3B directly on the laptop. Full access to every layer's internal state. Extract actual activation values from three layer groups and use those as the x/y/z coordinates for the Three.js visualization. The problem: TransformerLens does not support this model's architecture yet — issues with the Mistral 3 config, which is still early in development. Solution: use raw PyTorch hooks instead. The tradeoff is it runs on CPU, meaning you pre-generate the point cloud offline in approximately three minutes and serve a static points.json to the Three.js visualization.

Scenario B is the right answer scientifically. Scenario A is the right answer for a hackathon with less than 24 hours left.

The Decision Nobody Tells You About

Here is what the hackathon documentation does not prepare you for: the moment when you have to choose between the project you believe in and the project you can actually ship tonight.

Scenario B is oourmind as it should exist. Real activation layers. Genuine mechanistic interpretability. The model's internal state extracted, not reported. That is the product. That is what makes the visualization honest.

But Scenario B requires a backend that is not built, a library that does not yet support the architecture, and a CPU runtime that takes three minutes to generate a point cloud — on a deadline measured in hours.

Scenario A ships tonight. Scenario B ships in three weeks.

I chose Scenario A.

What This Actually Means for the Project

Here is the thing that this analysis made clear, even if neither of us said it explicitly at the time:

The gap between Scenario A and Scenario B is the product.

The model telling you what it thinks it is doing versus what it is actually doing inside — that gap is the entire problem oourmind exists to solve. It is what Michael Burry was writing about when he surfaced an 1880 Smithsonian presentation about a deaf-mute who reasoned about the origin of the universe before he had any language. It is what Foucault meant when he wrote that power is tolerable only on condition that it mask a substantial part of itself.

The self-reported coordinates of Scenario A are a perfect metaphor for the current state of AI transparency. The model gives you a number. You have no way to verify it. You trust it because it is the only option available.

oourmind is being built to make Scenario B the default. For everyone. Not just for researchers with local GPU clusters and three minutes to spare.

What You Actually Do With Less Than 24 Hours

You stop building the product and start building the argument.

The Three.js scene works. The Blue Grid is merged into main. The personas are visible in space. That is enough for a demo.

What you spend the remaining hours on is making sure the person watching the demo understands why it matters. The founder statement. The submission description. The one sentence that lands before anything else:

"Every AI model has a shadow. Nobody shows you when it activates."

The code is the proof of concept. The argument is the submission.

A Note on Collaboration Under Pressure

The decision I made at 5:43 AM — Scenario A, frontend only, submit the argument — is the right decision. I know that because making it felt like giving something up. The best hackathon decisions usually do.

What Comes Next

oourmind.io is the vision. The next step is Scenario B — real activation layers, genuine interpretability, the model's internal state made spatial and felt rather than self-reported and approximate.

*Built for the Mistral AI Hackathon, March 2026. *

Find me in the wild: humiin.io

The Design Gap: Why AI’s Biggest Risks Are Not Engineering Problems

Soumia — Mon, 02 Mar 2026 13:29:48 +0000

"You should always know what is yours. In your product, in your model, in your team."

There is a quiet crisis in AI development that nobody talks about directly, because it lives in the gap between disciplines.

Two of the most critical challenges in deploying AI responsibly—making it understandable to non-experts and making it resistant to adversarial manipulation—are fundamentally design problems. Not engineering problems. Not research problems. Design problems.

And yet, designers are almost entirely absent from both conversations.

Part One: Accessibility is Sitting Under the Data Scientist’s Desk

Walk into any AI team today. You will find machine learning engineers, data scientists, and perhaps a researcher. If you are lucky, a product manager. What you almost never find is a designer who has been given serious responsibility over how the model’s behavior is communicated to the people who use it, govern it, or are affected by it.

This is a structural problem masquerading as a technical one.

The Measurement vs. Communication Gap

When a model produces a confidence score of 0.87, that number means something precise to the data scientist who trained it. But to a hospital administrator deciding on a diagnosis, or a loan officer reviewing a credit decision, it means almost nothing. Or worse, it leads to automation bias.

The Data Science Output	The Human Reality	The Design Fix
0.87 Confidence	Anchoring on a number without context.	Visualizing Uncertainty Ranges.
Saliency Maps	"Rainbow noise" that non-experts ignore.	Progressive Disclosure of reasoning.
Raw Logits	Technical noise.	Natural Language Guardrails (e.g., "The model hasn't seen this case before").

The data scientist has solved the measurement problem. Nobody has solved the communication problem. This requires deep thinking about mental models and cognitive load theory—disciplines that have sat in the design world for decades, yet aren't being invited to the table.

Part Two: Security is Being Handled by the Wrong People

The second gap is more urgent. AI security—specifically protecting LLMs against adversarial manipulation—is currently owned by red teams and safety researchers. They test for jailbreaks and prompt injections.

They are doing vital work, but they are doing it too late. Today’s approach is reactive: build the model, try to break it, patch the hole. This is the 1990s software security paradigm applied to a 2026 problem.

The Design Problem Inside Security

Adversarial robustness is partly a design problem. Specifically, a problem of purpose, structure, and constraint.

Goal Hijacking (ASI01): This works because the model has no stable, legible representation of its own goals.
Prompt Injection (ASI02): The "attack surface" is the entire distribution of human language. You cannot patch it exhaustively; you must design it out.

The future of AI security looks less like penetration testing and more like constitutional design. We need to make security visible. One of the greatest risks is that a goal-hijacked model looks identical to a functional one from the outside. If we can make internal reasoning states legible, we can detect a hijack before the response is even complete.

A 146-Year-Old Warning

In a recent piece—"History Rhymes: Large Language Models Off to a Bad Start?"—Michael Burry surfaces a presentation from 1880 regarding the case of Melville Ballard. Ballard was a deaf-mute teacher who, before acquiring language, was already reasoning about causality and the universe.

The conclusion? Complex thought exists in the silence before words.

Burry’s argument is that LLMs built language first, but reason was never the foundation. They are "increasingly sophisticated mirrors" rather than entities of understanding. The most striking line from that 1880 presentation was this:

"The expression of the eye was language which could not be misunderstood."

Real understanding communicates through something more direct than words. Something spatial. Something felt.

The Convergence: From Numbers to "The Eye"

These three threads—accessibility, security, and Burry’s philosophical challenge—are the same problem viewed from different angles: The inside of these systems is not legible to the humans who depend on them.

Burry’s solution—his image of real understanding—is not a better dashboard or a more precise interval. It is the "expression of the eye." It is spatial and direct.

That is the design challenge. Not to build better number displays, but to build systems where a model’s internal state can be experienced. We need interfaces where a non-expert can feel when a model is reasoning cleanly versus "hallucinating" or reaching, and where an operator can see a safety risk forming in 3D space before it manifests in text.

🏛️ The Artifact: oourmind.io

I am attempting to bridge this gap during the Mistral Hackathon (March 2026).

oourmind.io is a real-time interpretability lab that visualizes the internal reasoning state of Mistral-Large-3 as a navigable 3D environment. It is an attempt to make the inside of a model felt rather than merely read.

Are you designing the "eye" of your AI, or just the buttons?
I’m curious how other teams are handling the communication of uncertainty. Let’s discuss the architecture of legibility.

By Soumia — LinkedIn · Portfolio