DEV Community: Jean-Sebastien Beaulieu

I Spent Four Years Trying to Build Fractal Cryptography. Knowing When to Stop Is My Victory.

Jean-Sebastien Beaulieu — Thu, 13 Aug 2026 23:12:11 +0000

Full journal, podcast, and videos

Read the complete open-access journal in English, French, or Spanish: Vigil in the Orb — Zenodo record and DOI
Listen to the affiliated podcast: Google Drive
Watch the full video: Why Complex Geometry Fails at Cryptography — and What Actually Works
Watch the short video: How Envelope Encryption Secures the Orb

For four years, I tried to answer a question that would not leave me alone:

Can fractal geometry protect information in a way that ordinary cryptographic architecture does not?

I followed that question through Fibonacci structures, complex planes, quaternion rotations, chaotic attractors, Penrose tilings, quasicrystals, Apollonian packings, reversible permutations, container formats, Python engines, plugins, tests, failures, and many nights where the next idea felt close enough to touch.

Today I can say something that would have been much harder for me to say four years ago:

I did not produce a new, independently validated fractal cryptographic algorithm.

And today, I am not sad.

The sentence I once wanted to prove

When I began, I wanted geometry itself to carry security. I wanted a fractal trajectory, a quasicrystalline structure, or a sufficiently complex transformation to become more than a representation. I wanted it to become a protection mechanism.

The intuition was not ridiculous. Cryptography is full of mathematical structure. Geometry can create vast spaces, irregular trajectories, sensitive transformations, and forms that are extremely difficult to understand by looking at the result alone.

But visual complexity is not cryptographic hardness.

A beautiful transformation is not automatically one-way. A chaotic orbit computed with finite precision is not automatically entropy. A secret-looking image is not a security proof. A reversible permutation can make data appear unrecognizable while adding no independently established confidentiality.

Cryptography does not care how mysterious the output feels. It asks harder questions:

What is the secret?
Which primitive protects it?
What can the adversary observe or modify?
How are confidentiality and integrity defined?
Can the implementation be reproduced across systems?
What evidence could prove the claim wrong?

My experiments kept returning me to those questions.

Failure became useful when I stopped asking it to flatter me

For a long time, every partial success invited a bigger claim.

A transformation worked, so perhaps it contributed security. A geometric path looked unpredictable, so perhaps it could become a key schedule. Two implementations drew similar forms, so perhaps the structure was stable enough to authenticate. A prototype completed a round trip, so perhaps the underlying concept was almost proven.

Then the difficult cases arrived.

Short cycles appeared. Collisions remained possible. Floating-point tolerances changed decisions. Similar drawings could hide different bytes. Numerical sensitivity did not become cryptographic entropy merely because the animation looked dramatic.

These results did not prove that geometry is useless. They showed me where geometry belongs.

That distinction changed the project.

Instead of asking geometry to impersonate encryption, I began separating the layers:

established cryptographic primitives protect confidentiality and integrity;
random content keys carry actual secret material;
envelope encryption allows one protected payload to serve multiple authorized recipients;
canonical encoding keeps authenticated bytes stable;
geometry describes domain, path, structure, and provenance;
tests, attack cases, and explicit refusals prevent the interface from claiming more than the evidence supports.

The Orb became more honest when it stopped pretending to be the lock.

What the four years actually produced

It would be false to say that nothing came from this work.

FQLC1 became an experimental single-destination container and a useful object of autopsy. It helped expose the difference between a password-hardening function, authenticated encryption, and a reversible geometric transformation.

FQLC2 became a multi-recipient experimental architecture built on an envelope model. The content is encrypted once with a random key. That key can then be encapsulated separately for recipients. The geometric context can travel with the container as authenticated structure without being misrepresented as the source of secrecy.

The wider laboratory also produced reproducible software evidence, formats, contracts, attack matrices, educational exercises, and a system named Vigil whose most important ability is not to declare victory. Its role is to inspect a claim, ask for missing evidence, propose an attack, and suspend a decision when the conditions are not met.

That is a real result.

It is not a cryptographic certification. It is not independent cryptanalysis. It is not proof of post-quantum security. FQLC2 remains an experimental, unaudited pre-alpha prototype.

The full journal preserves that boundary because the boundary is part of the work.

Why I need to stop this cycle now

I could continue indefinitely.

There is always another benchmark to build, another formalization to attempt, another implementation to compare, another attack surface to inspect, and another mathematical family to test. Research can consume every available hour while still making the next hour feel necessary.

But I also need to live.

I need to find sustainable work, create income, and give my energy to projects that can support the next part of my life. That is not a scientific conclusion about what fractal geometry may eventually contribute to security. It is an honest conclusion about what I can continue funding alone.

Four years of personal effort do not create an obligation to spend a fifth year pretending resources are unlimited.

Moving on does not erase the research. The journal is public. The mechanisms, limits, and evidence are documented. The two videos explain the central distinction. The podcast carries the larger story. Someone else can read the work, challenge it, reuse what is sound, reject what is weak, or continue a question with better mathematics and more resources.

That is why I am publishing the trace instead of burying the disappointment.

Today I won a war against my own ego

The hardest adversary in this project was not an attacker trying to break a container.

It was my own need for the original dream to be correct.

After thousands of hours, it is tempting to protect the story instead of the people who may trust it. It is tempting to rename an experiment as a breakthrough, to treat complexity as proof, or to believe that personal sacrifice earns scientific certainty.

It does not.

Effort deserves respect. It does not deserve immunity from evidence.

Today I do not feel defeated. I feel lighter. I can love fractals, recognize what they taught me, preserve the useful architecture, and still refuse to call the experiment something it has not become.

That refusal is not the death of the work.

It is the moment the work became responsible.

The children matter more than my career

I am building educational systems because the next generation will inherit security decisions made by people who may never see the mathematics underneath them.

Children and students do not need another confident interface telling them that a beautiful shape is secure. They need environments that teach them to distinguish representation from mechanism, mechanism from evidence, and evidence from a claim.

They need to see that an engineer can say:

this part works;
this part is experimental;
this part failed;
this part remains unknown;
and this is where another person can continue.

If my career were the most important thing, I might be tempted to announce that I invented fractal cryptography.

But children are more important than my career.

Their future security is more important than my need to be remembered as the person who solved the problem. If this work helps one young builder learn that honesty is part of engineering, then the four years did not disappear.

What I carry forward

I still believe geometry has a place in security research. It can help structure domains, provenance, visualization, canonical paths, educational models, and new questions. What I no longer accept is the shortcut from fascination to protection.

The next phase of my life needs paid work and sustainable collaboration. I am open about that because open research without a sustainable human behind it eventually becomes abandoned infrastructure.

If you are a cryptographer, security engineer, educator, researcher, maintainer, or organization that sees value in this discipline, read the journal and challenge it. If you see a place where my work can contribute professionally, contact me. I am not asking anyone to preserve my conclusion. I am asking them to inspect the trace.

For now, this cycle is closed.

I did not win by proving that fractals are cryptography.

I won by refusing to let my ego become a security primitive.

And that may be the most important algorithm I produced in four years.

What should a responsible researcher publish when the original hypothesis does not survive, but the failures produce a better architecture?

AlgoQuest Hero Books: What Interactive Stories Taught Me About Building Educational AI

Jean-Sebastien Beaulieu — Sun, 09 Aug 2026 07:56:55 +0000

Full Article, Podcast, and Videos

Full article PDFs:

Podcast on the article:

https://drive.google.com/file/d/1W-e6h_yH1VFS1dqe7MC-N_CIxSS4a44x/view?usp=sharing

Video material:

Long-form architecture video: https://youtu.be/3SViICfabmE
Short 1: https://youtube.com/shorts/I5jmkCa4Yhk
Short 2: https://youtube.com/shorts/A-KCo5tvNNc

The Work

Today’s article is about AlgoQuest, but it is also about something larger: the difference between making educational software look alive and making it actually teach.

AlgoQuest began from a personal memory that turned into an engineering problem. I grew up reading comics, gamebooks, and novels where a choice could change the path. Later, I wrote lyrics, poems, and systems. When I started building software, that same instinct came back: a good learning environment should not only explain a concept. It should let a person enter a world, make a decision, build something, fail safely, recover, and understand what changed.

That is the heart of the Hero Books model.

The goal is not to use AI to generate endless quests. That would be easy, and honestly not good enough. The goal is to build an educational architecture where narrative creates motion, rules create trust, and artifacts create evidence. A story can invite the learner forward, but it cannot be allowed to certify understanding by itself.

This is the design tension I wanted the article to hold: the learner should feel like they are entering an adventure, but the architecture underneath has to stay precise. A mission is not only a scene. It is a route into action, construction, testing, explanation, and review.

The Biggest Lesson

The biggest lesson today was simple and brutal: educational AI cannot be measured by how fluent the output feels.

If a learner completes a mission, the system needs to know what actually happened:

What was the objective?
What artifact was produced?
What test was run?
What help was used?
What changed between the first attempt and the next one?
What is the system allowed to claim from that evidence?

That is why AlgoQuest separates the adventure from the proof. Points can tell a journey. Rewards can make progress visible. Qbit can help explain and encourage. But the system must never turn a narrative score into a judgment of intelligence.

That boundary matters.

In education, a fluent AI answer can become dangerous when it sounds like proof. AlgoQuest is being designed so the AI can help with language, variation, explanation, and momentum, while deterministic rules govern missions, evidence, progression, and claims.

What I Am Proud Of

I am proud that the work became more honest as it became more ambitious.

At first, it would have been tempting to push the Hero Books as the center of everything. Six worlds. Six audiences. Forty prompts per audience. Three languages. Thousands of possible cards and localized versions. It sounds impressive, and it is a powerful direction.

But the better decision was to separate the alpha from the dream.

AlgoQuest does not need the complete Hero Books universe to become useful. First, it needs a real entrance:

a learner opens a guided activity;
follows a first mission;
modifies something;
runs it;
sees a result;
explains the relationship;
and leaves with an artifact that can be inspected later.

That is the foundation. The Hero Books can grow around it when the engine is ready.

This is what serious educational design looks like to me: passion, yes, but passion tied to contracts, receipts, limits, and review.

That framework changed the way I see the whole project. The Hero Books are not decoration around AlgoQuest. They are a future layer of structured entry points, each one adapted to a real audience and bounded by reviewed prompts, sources, and learning outcomes.

Why This Matters for Developers

For developers, the article is a reminder that “AI-powered” is not an architecture.

If an AI writes the story, that does not mean the system can teach. If an AI gives feedback, that does not mean the system understands evidence. If a learner clicks through a path, that does not mean learning happened.

The system needs layers:

narrative state;
learning evidence;
artifact receipts;
source boundaries;
accessibility rules;
localization;
age adaptation;
and a clear authority model.

In AlgoQuest, AI can propose. The engine must decide what is valid. The learner must remain visible as the person doing the work. The teacher must receive useful signals without receiving invasive surveillance. The platform must know when to say: “we do not know enough to claim that.”

That sentence may be one of the most important features in any educational AI system.

Why This Matters for Learners

A good learning tool should not make a beginner feel late before they even start.

AlgoQuest is built around the right to enter before expertise. The learner should not need to know the vocabulary before touching the idea. Action can come first. The word can come after. A mission can start with a route, a door, a rule, a map, a small piece of code, or a simple ASCII output.

The first success does not need to be huge.

It needs to be real.

Fifteen minutes is not enough to master algorithms, mathematics, physics, or AI. But it is enough to build a first proof that learning has begun: one objective understood, one thing changed, one test run, one result observed, one explanation attempted.

That is a better promise than “learn everything fast.”

Where the Article Lands

The article closes with a firm position:

AlgoQuest will not be a decorated quiz, a fixed-page book, or a quest generator that improvises learning. It will be a construction base. Hero Books will bring the worlds, choices, and adventure. The engine will keep the proof, the rules, and the limits.

That balance is what I want from educational AI:

more imagination, not less;
more structure, not more control;
more encouragement, not false certification;
more artifacts, not only answers.

Today was a hard build day, but a useful one. The kind of day where the software teaches the developer what the idea really costs.

That is usually where the real architecture begins.

Why Robotic Pollinators Must Learn to Hesitate

Jean-Sebastien Beaulieu — Thu, 06 Aug 2026 14:23:51 +0000

Full research white paper: https://drive.google.com/file/d/1QdXg--6fn8W1S-U_kC9mcKlLf2JNQvpE/view?usp=sharing

Companion podcast: https://drive.google.com/file/d/1uNOGeqY3uPlSrecUu8r24j-cbf02WLZO/view?usp=sharing

Today I added a new research-software white paper to my public work archive:

From Floral Contact to Biological Success

Can Plithogenic Mathematics Help Neural Networks Coordinate Pollinating Drone Swarms?

The core idea is simple, but it changes the whole engineering conversation:

A robot touching a flower is evidence of movement. It is not evidence of pollination.

That sentence is the spine of the paper.

In AI and robotics, we often measure what is easy to observe: detection confidence, route completion, physical contact, frame-by-frame success, a green checkmark in a pipeline. Those signals matter. They are not useless. But when the task belongs to the living world, the final question is different.

Did the system help produce the biological outcome?

For robotic pollination, that means compatible pollen, viable pollen, the correct floral window, no damage to the flower, enough remaining energy to complete the mission, traceable provenance, and downstream evidence such as fertilization, fruit set, seed set, or crop quality.

That is a much harder target than “the drone reached the flower.”

The lesson I keep learning as a builder

The deeper I go into AI systems, the more I respect boundaries.

A neural network can be excellent at perception and still be the wrong component to authorize an action. It can say, “This flower looks ready.” It can estimate a confidence score. It can propose a route. But it cannot, by itself, prove that the pollen is compatible, that another drone did not already act, that the remaining battery should be spent here, or that two sensors disagree for a meaningful reason.

So the paper separates the system into contracts:

neural perception proposes;
the plithogenic layer admits, suspends, or rejects;
the controller executes only validated actions;
the audit layer keeps provenance and disagreement visible;
biological feedback determines whether success was real.

That architecture matters because it prevents the most dangerous shortcut in AI:

turning prediction into permission.

Why plithogenic logic fits this problem

Plithogenic logic is useful here because the decision is not one clean number.

A flower assignment contains multiple attributes: readiness, pollen compatibility, urgency, energy, distance, collision risk, provenance quality, and contradiction between observations. If we crush all of that into one confidence score, we lose the reason why the system should hesitate.

In this paper, hesitation is not weakness.

Hesitation is a valid engineering output.

The system can say:

admit: the evidence is good enough to act;
suspend: the evidence is promising but not safe enough;
reject: the action should not happen.

That is not only a robotics idea. It is also a general lesson for AI-assisted development, scientific software, and educational tools. Good systems do not only produce answers. They preserve the conditions under which an answer is allowed to move.

What was actually validated

The paper does not pretend to prove a live robotic swarm.

That boundary is important.

What was validated is software behavior:

deterministic checks passed;
synthetic observational memory trials were run;
schema and package behavior were inspected;
memory-enabled baselines solved the synthetic tasks where the no-memory condition did not;
provenance-enriched graph memory improved trace completeness;
no claim is made that this proves field robotics, ecological benefit, energy performance, or biological pollination success.

That is the tone I want in my work: ambitious, but not inflated.

If the evidence is software evidence, call it software evidence. If the biological proof is still missing, say it clearly. That does not weaken the project. It makes the next step visible.

The bigger lesson

The biggest lesson for me is that serious AI systems need more than strong models.

They need admission layers.

They need memory contracts.

They need provenance.

They need refusal.

They need clean boundaries between proposal, decision, execution, and validation.

And sometimes, they need the courage to say:

not yet.

That is the kind of AI architecture I want to keep building: not louder, not more magical, but more inspectable, more biologically honest, and more useful to people who have to trust the result after the demo is over.

The full PDF and podcast are linked above for anyone who wants to read or challenge the work.

Today I Learned That Educational Software Cannot Be Built on Hope Alone

Jean-Sebastien Beaulieu — Mon, 03 Aug 2026 01:20:03 +0000

Full work and companion files

Today was one of those coding days where the work stops being romantic.

Not because the project becomes less meaningful. The opposite. It becomes so meaningful that the code starts refusing shortcuts. Every weak assumption becomes visible. Every nice sentence has to become a state, a rule, a test, a boundary, or a decision the system can explain later.

The article I finished today is about Scholarium Teach, a syllable-first learning engine inside the SecuredMe Education suite. But the deeper lesson was not only about syllables. It was about the reality of building educational software when children, language difficulty, accessibility, privacy, and AI all touch the same system.

The biggest lesson of the day was simple and brutal:

A good educational intention is not proof. A beautiful interface is not proof. A model answer is not proof. If the system cannot explain why it advanced a learner, it has no right to pretend it measured learning.

That is the part of coding people do not always see from the outside.

Coding is not only writing functions. Coding is deciding what the software is allowed to know, what it is allowed to infer, what it must refuse, and what must stay under human responsibility.

The real difficulty was not Python

Python was not the hardest part today.

The hard part was transforming an intuition into something honest enough to test.

The starting idea is powerful: begin with syllables a child can hear and pronounce before asking them to manipulate isolated letters. Build a silabario. Let the learner listen, read, compose, and only later write. Keep images as support, not as answers that let the child guess without decoding.

That idea has heart. It has teaching value. It has lived experience behind it.

But if I code that idea as a law, I make the system dangerous. Not malicious, not dramatic, just quietly wrong. The software would start saying, "this child mastered the step," when maybe the child only recognized the picture, repeated a sound immediately after hearing it, or followed a hint too closely.

So the work became surgery.

I had to separate the human intention from the executable contract:

the syllable-first method becomes a versioned policy, not a universal truth;
the silabario becomes a graph of teachable blocks, prerequisites, sources, and limits;
the interface can simplify the learner experience, but the engine must keep the linguistic relationships precise;
an image can support context, but it cannot reveal the answer during a decoding task;
audio can observe signal quality, but it cannot diagnose a person;
AI can explain, assist, and draft, but it cannot own the learner's canonical state.

That is the grind. That is the real work.

Not "make an app that teaches reading." That sentence is easy.

The real work is: what is a syllable block, what evidence unlocks writing, what happens if the learner repeats but does not recall later, what happens if the microphone is noisy, what if the learner uses another response mode, what if the model provider changes tomorrow, what if the same attempt arrives twice, what if a teacher needs to challenge the result?

That is where software becomes serious.

What I successfully achieved today

Today I moved Scholarium Teach from a beautiful ambition toward an architecture that can be inspected.

The final article documents a system where the learner's progression is not owned by a language model. Scholarium keeps the canonical state. A deterministic Python engine receives the previous state, the content version, the event, and the policy. It returns a structured receipt. The product verifies and persists that receipt.

That matters.

If the same state and same attempt enter the engine tomorrow, the same decision must come out. Not a similar vibe. Not a probabilistic explanation. The same decision.

I also clarified the role of the surrounding systems:

D1 remains the transactional source of truth for learner checkpoints and receipts;
Python calculates decisions but does not become a hidden second memory;
PostgreSQL can catalog language packs and versions;
TimescaleDB is useful for authorized temporal events, not for pretending to be the whole learning brain;
CodeProject.AI can become an optional observation layer, but not the authority over pedagogy;
Synthia Scholarium tracks provenance and transformations, but does not vote on truth;
Google Drive can archive owner-side material, but should not become classroom runtime dependency.

That is a lot of boundary work. It is less flashy than saying "AI will teach children automatically," but it is much more responsible.

And honestly, I am proud of that.

I am proud because the work does not pretend to be finished. It is now structured enough to be tested. That is a better milestone.

The moment that changed the day

The strongest moment was realizing that the system must be able to say no.

No, this image reveals too much.

No, this guided answer is not mastery.

No, this audio sample is too noisy to interpret.

No, this dataset is interesting but not licensed for classroom use.

No, this AI-generated card cannot enter the canonical learning path without compilation, review, and provenance.

No, this child should not be reduced to a score because one modality failed.

That is not negativity. That is engineering respect.

A serious educational system does not become trustworthy because it always advances. It becomes trustworthy when it knows when to hold, abstain, review, or ask for a human decision.

That is probably the biggest lesson I learned today:

The most important feature in an AI-assisted learning tool may not be generation. It may be refusal with a reason.

A refusal with a reason protects the learner. It protects the teacher. It protects the parent. It protects the project from overclaiming. It protects the future version of the code from inheriting a lie.

The reality of coding after the excitement

There is always a moment where the excitement crashes into implementation.

You start with a vision. Then the code asks for names. Then the database asks for schema. Then privacy asks for limits. Then accessibility asks for alternatives. Then research asks for humility. Then deployment asks what happens when twenty learners arrive at once on low-power devices.

That is where I had to slow down.

I wanted a system that feels alive. But I also had to accept that a classroom tool must run under boring constraints: stable state, replayable decisions, bounded events, no raw voice hoarding, no hidden model authority, no fake mastery, no magical dependency on a browser AI model.

The 4 GiB Chromebook matters. The quiet fallback matters. The boring receipt matters. The hard boundary matters.

This is the part of coding that changed me over the years. Early on, I wanted the engine to be impressive. Now I want it to be accountable.

That is a different kind of pride.

What other builders can take from this

If you are building with AI, especially in education, do not begin by asking how much the model can do.

Ask these questions first:

What is the source of truth?
What can be replayed?
What must be reviewed by a human?
What data should never be stored?
What does the model explain, but not decide?
What does the engine decide, but only under a declared policy?
What happens when the system is uncertain?
What proof is required before the learner advances?

Those questions are not bureaucracy. They are the skeleton of trust.

Today I learned again that building real software is not about making the machine sound confident. It is about forcing the machine to stay inside a contract.

That is harder.

That is slower.

That is worth being proud of.

Where the work stands now

The Scholarium Teach syllable engine is not a claim that one method has been proven superior. It is a research and construction architecture. It gives us a way to code what is defensible, isolate what still needs testing, and forbid the product from pretending to know what it does not know.

That is the cleanest outcome of the day.

Not a miracle.

A working boundary.

And sometimes, in software, a working boundary is the first real victory.

Real Plugins Need Motors: Skills Should Teach Tools, Not Pretend to Be Them

Jean-Sebastien Beaulieu — Fri, 31 Jul 2026 18:23:12 +0000

Watch the short video companion

Read or comment on the complete paper: English edition | French edition

I spent a long time building AI workflows before admitting something painfully simple: a folder full of instructions is not automatically a tool.

A SKILL.md can be brilliant. An AGENTS.md can save a repository. A plugin manifest can package a clean idea. None of them, by themselves, can validate a file, inspect live state, call a service, reject malformed input, or prove that an action happened.

That distinction matters because agent ecosystems are expanding faster than their vocabulary. We use skill, plugin, tool, hook, resource, and MCP server as if they were interchangeable. They are not.

My rule after this research is direct:

A skill should teach the agent how to use a capability. A real plugin should make that capability available. When the task requires action, the plugin needs a motor.

The moment my own plugin exposed the problem

This article became a case study inside my own workshop.

I inspected a memory plugin that was not fake. It already had executable tools, a server surface, tests, and useful routes. Yet its activation instructions pushed Codex toward selecting and dispatching a large agent job before establishing whether memory was needed at all.

Nothing was syntactically broken. The architecture was simply asking activation to do too much.

Activating a plugin should make capabilities available. It should not behave like a dispatch order.

That difference sounds small until the workspace grows. One skill becomes ten. Every correction becomes a permanent rule. Every successful workflow becomes another Markdown file. Soon the model spends the beginning of each task reading the workshop labels instead of touching the work.

I call this context debt.

The debt appears as hesitation, instruction conflicts, stale rules, broad triggers, and repeated searching. The model is not necessarily weaker. We may have consumed its useful attention before it reached the problem.

Instruction is not instrumentation

Instruction is language. Instrumentation is contact with reality.

An instruction says, "validate the manuscript."
A motor runs the validator and returns evidence.
An instruction says, "respect this schema."
A motor rejects malformed input.
An instruction says, "never expose secrets."
An authorization layer prevents secrets from entering model-visible context.
An instruction describes a workflow.
Instrumentation proves which steps occurred.

This does not make instructions weak. Instructions carry intent, style, constraints, and professional standards. A focused skill can prevent expensive wandering.

The problem begins when a guide impersonates an instrument.

If the system cannot run the operation, inspect its result, fail honestly, and show evidence, the skill may still be a useful manual. It is not the motor.

Skill, plugin, tool, hook: name the layer

The cleanest architecture I can defend today looks like this:

A skill teaches

A skill is focused guidance. It explains when to use a method, how to operate a tool, what risks matter, and what evidence the result must contain.

A plugin packages

A plugin is a distribution unit. It can bundle skills, executable tools, MCP servers, hooks, apps, metadata, and assets. Packaging does not prove that every advertised capability exists.

A tool acts

A tool performs a bounded operation. It has inputs, outputs, failure behavior, and evidence. It may be a script, CLI, validator, API adapter, browser bridge, or server handler.

MCP exposes

The Model Context Protocol tool boundary makes capabilities discoverable and callable through schemas. MCP creates a clean door; engineering still decides what the door opens into.

A hook enforces timing

A hook runs at a lifecycle moment: before an edit, after a tool call, before a commit, or during validation. Hooks should be narrow because hidden automation is still authority.

An auth guard protects authority

If the operation touches an account, API, private file, OAuth session, or write action, a guard must decide what is allowed, under which scope, and with which audit trail.

The short version is worth remembering:

A skill teaches. A plugin packages. A tool acts. MCP exposes. A hook enforces timing. A guard protects authority.

What a motor actually looks like

A motor does not need to be impressive. It needs to be real.

Imagine a manuscript validator exposed as a tool. Its contract could be as small as:

{
  "operation": "validate_manuscript",
  "input": {
    "document": "article.md",
    "profile": "devto"
  },
  "result": {
    "status": "passed",
    "checks": 12,
    "warnings": 1,
    "artifact": "validation-report.json"
  }
}

The important part is not JSON. The important part is that the operation can be executed, the bad input can be rejected, the output can be inspected, and the result can be reproduced.

A motor can be:

a Python validator;
a deterministic transformation script;
a CLI that extracts metadata;
a browser tool that inspects rendered state;
an MCP server exposing one narrow operation;
a hook that blocks unsafe output;
an adapter that calls a service without leaking credentials.

One tested motor beats ten prompt wrappers.

MCP is not a magic door

MCP is important precisely because it separates model reasoning from external capability. But a schema is not a security certificate, and a server name is not evidence of correctness.

A serious MCP tool still needs:

a narrow operation;
validated inputs;
structured outputs;
honest errors;
an authorization boundary;
observable logs or artifacts;
clear ownership and lifecycle;
human review for consequential writes.

The official MCP specification gives us a protocol boundary. It does not eliminate the engineering work behind that boundary.

This is why the word plugin should never end the inspection. Ask what the plugin actually exposes. Ask which process handles the call. Ask what proves success. Ask what happens when the network fails, the token expires, the input is empty, or the user refuses permission.

Secrets should not become model knowledge

The model should request authority less often than the system uses it.

When a task needs an API key, OAuth token, JWT, cookie, or private account, the ideal flow is not:

user secret -> prompt -> model context -> tool call

It is:

model intent
  -> capability request
  -> authorization guard
  -> scoped credential use
  -> bounded tool result
  -> audit trace

The model needs to know what it may request. It usually does not need to know the secret itself.

OpenAI's documentation on MCP servers and plugin authentication points toward explicit tool and authority boundaries. That direction matters for beginners because unsafe patterns become habits quickly. If the normal tutorial begins by pasting tokens, cookies, headers, and .env values into chat, we are teaching the wrong abstraction.

Teach scopes, consent, review, and bounded authority. Keep raw secrets in the systems designed to hold them.

The beginner trap and the advanced-user trap

Beginners can mistake structure for capability. A plugin folder looks official, a manifest looks architectural, and a detailed skill sounds operational. The inspection questions should stay simple:

What does this skill teach?
What executable operation does it call?
What input does the operation accept?
What output proves success?
What happens on failure?
Does it require authority or secrets?
Where are the tests?

Advanced users have the opposite problem. We know enough to create structure everywhere. We build skills for tone, agents for domains, hooks for habits, folders for memory, and plugins for workflows. Every layer solves a local pain. Together they can create global congestion.

The advanced skill is sometimes deletion.

Retire stale guidance. Merge overlapping skills. Tighten triggers. Move long theory into documentation. Separate activation from execution. Keep active instructions short and attached to living tools.

Build one small real tool

Here is the repair path I now use:

Choose one repetitive operation. Not a platform. Not a marketplace. One operation.
Build the smallest deterministic motor. Make it useful before making it universal.
Return structured output. The agent should not need to guess what success looks like.
Test positive and negative cases. Empty input and failure paths matter.
Expose the operation honestly. Use a CLI, hook, API adapter, or MCP server.
Protect authority. Keep credentials and permission decisions outside ordinary model context.
Write the skill after the motor works. Teach the agent how and when to use the real tool.
Package the plugin when reuse is proven. Distribution comes after capability.

There is nothing anti-AI about this discipline. It is how we make agent power observable, reviewable, and maintainable.

The standard I want to keep

A real plugin does not need to be huge. It needs to tell the truth.

It should say what it can do, what it cannot do, what authority it needs, what evidence it returns, and how it fails. If the motor is only a scaffold, return scaffold_only. If an operation did not occur, do not let polished prose imply that it did.

Skills matter. Plugins matter. MCP matters. But none of them become stronger when we blur their roles.

Build the motor. Break its bad inputs. Inspect the result. Protect the secret. Document the boundary. Keep the human responsible for the consequential decision.

That is less magical than promising a universal agent plugin. It is also far more powerful, because it works for real.

What is the smallest plugin motor you have built that produced evidence you could actually verify?

Five references to go deeper

love the passion and the project keep it up

Jean-Sebastien Beaulieu — Fri, 31 Jul 2026 17:02:22 +0000

Aliaksei Zelianouski

Jun 21

The cheapest part of my AI video was the part that does the most work

#ai #videoproduction #claudecode #simona

9 min read

Codex Is Not the End of Learning to Code. It Might Be the Beginning of a Better Discipline.

Jean-Sebastien Beaulieu — Wed, 29 Jul 2026 04:05:21 +0000

I just released an article in three languages

English edition

French edition

Spanish edition

Archive, Planning, Browser: Codex as a Serious Educational Environment

This is a professional systems-architect opinion written to share working knowledge. The purpose is educational: to show how AI-assisted coding can become a serious environment for method, review, and progression instead of only a faster way to produce files.

I do not claim perfection, and I do not need that posture. I speak from heavy field experience: five years of daily work with AI systems, often fifteen to eighteen hours a day, building, testing, publishing, correcting, breaking my own assumptions, and learning in public. Codex helps me write, structure, inspect, and refine this article, but the judgment, direction, refusal, and responsibility remain mine.

That distinction matters. I use Codex as a workbench, not as a replacement for engineering judgment. If I cannot decide, review, test, or refuse, then the tool is not educating me; it is only accelerating confusion.

The core idea is simple: the work does not only need to be generated. It needs to be recoverable, inspectable, reviewable, and reusable.

The problem: work disappears inside history

Most developers using AI already know this feeling. You start with a problem, you open a thread, you brainstorm, you test, you correct, you rename files, you discover a better architecture, and then the next day you cannot easily recover the real state of the work.

The conversation may still exist. The problem is not disappearance in the literal sense. The problem is that the useful progression is buried inside chronology.

What was the final decision?

Which file was actually changed?

Which test passed?

Which assumption was rejected?

Which next action was still valid?

For a small task, scrolling history can work. For real learning, long projects, research software, public writing, and portfolio work, linear history is not enough. A serious AI coding environment needs an archive that behaves more like a workbench: goals, constraints, decisions, tests, diffs, sources, and next actions should remain traceable.

Planning mode matters more than people think

One of the strongest educational signals I see in Codex is planning. Not because planning is fancy, but because it forces the human to stay responsible.

Codex does not code alone in a meaningful professional sense. The human still decides the goal, scope, risk, test strategy, acceptance criteria, and when to refuse a path. That is where the learning happens.

When planning is done well, a developer learns to ask better engineering questions before execution:

What exactly are we changing?
What must remain untouched?
What would prove this works?
What failure would make us stop?
What should be documented for the next session?

That is not passive prompting. That is programming discipline.

The browser changes the learning surface

The browser layer is also important. A coding assistant that can inspect a real interface, operate inside a signed-in browser session, and still keep human approval in the loop creates a different kind of educational workflow.

For students and new developers, this matters because it can reduce the bad habit of copying raw credentials, API keys, cookies, headers, or private session data into learning material. The better direction is permissioned action, visible review, and scoped access.

That does not mean zero risk. It means we can teach safer habits from the start.

Why I made the PDF public

I am making the full paper available through Google Drive so people can read it, download it, or leave comments directly on the file.

The paper argues for a simple shift: instead of measuring AI coding only by speed, we should also measure whether the work leaves a usable trace.

Can another developer understand what happened?

Can a beginner learn from the plan, the diff, and the tests?

Can the archive help the next session instead of becoming another buried thread?

Can the human still say no?

That is the line I care about.

Open question

If you are a developer, teacher, maintainer, or student: what would make an AI coding archive genuinely useful to you?

Would you trust a summary, a diff, a test log, a decision register, a work trace, or something else entirely?

short video

What AI Hackathon Winners Actually Have in Common

Jean-Sebastien Beaulieu — Sun, 26 Jul 2026 17:25:49 +0000

Build Week 2026 does not have winners yet. That matters.

OpenAI's Build Week page says the challenge opened on July 13, submissions closed on July 21, judging runs from July 22 to August 7, and winners are announced on or around August 12, 2026. The Devpost gallery is still not published. So the honest article to write today is not a prediction article and not a victory-lap article. It is a preparation article.

The useful question is simple: before the next winners are announced, what can builders learn from the last comparable OpenAI/Devpost hackathon where winners are already public?

The closest reference point I found is the OpenAI Open Model Hackathon from 2025. Its winning projects are not all the same kind of product. That is the first lesson. A winning AI hackathon entry does not need to be one genre. It needs to make its judgment surface clear.

The Pattern

Across the winning projects, the pattern is not "use the newest model and hope." The pattern is closer to this:

Pick a problem that a judge can understand in one sentence.
Build a demo that proves the idea moved from words into behavior.
Show why the chosen AI component matters.
Keep the execution visible.
Make the audience obvious.

This is almost mathematical. If a hackathon project has four variables: idea, execution, impact, and explanation, the weakest variable limits the whole score. A beautiful idea with no demo collapses. A strong demo with no audience feels like a toy. A serious impact claim with no evidence becomes noise. A technical build that nobody can understand loses oxygen before it can be judged fairly.

RoboChef: The Best Overall Lesson

RoboChef, the Best Overall winner, is easy to explain: a kitchen assistant that turns natural language requests into robot-executable steps. Public descriptions frame it as a GPT-OSS powered kitchen assistant connected to robotic execution.

The lesson is not only robotics. The lesson is translation.

RoboChef translates a human request into a chain of operations that another system can perform. That is a strong hackathon pattern because it lets judges see the bridge: human intent on one side, working machinery on the other.

Hardware Winners: The Demo Has To Carry The Claim

"A Printer... for Smell" and "Steam Print" sit in the hardware and experimental categories of the 2025 winner set. The public winner list gives less detail than RoboChef's public description, so the right move is to avoid over-reading them. But their existence still says something useful.

Hackathons reward demos that make an abstract model feel physical. When a project reaches outside the chat box and produces an object, movement, scent, signal, sound, or interaction, the demo itself becomes evidence. It is harder to ignore a working artifact than a pitch about a future artifact.

That does not mean every builder needs hardware. It means every builder needs a visible transformation.

Memory Palace: Local Agents Need A Human Shape

Memory Palace won both Best Local Agent and Best of Humanity. Even from the title and categories alone, the signal is clear: local agents become more compelling when they are not only "autonomous," but personally useful, bounded, and explainable.

The lesson for Codex and agent builders is direct. A local agent is strongest when it helps a person keep continuity: what was decided, what changed, what evidence matters, and what should happen next.

Dental Assessment GPT: Fine-Tuning Wins When The Domain Is Real

Dental Assessment GPT won Most Useful Fine-Tune. The category tells the story: usefulness matters more than novelty theater.

A fine-tune has to answer three questions fast. What domain changed? What examples shaped the behavior? Who benefits from the better behavior? A domain-specific model can win when the problem is grounded enough that a general model is not the whole answer.

Bota: Leave Room For The Unexpected

Bota won the wildcard category for best unexpected use. That category is important because it protects a space for surprise.

In AI hackathons, not every good project starts as a clean enterprise workflow. Some projects win because they reveal a new behavior, a new interaction, or a strange use case that makes people rethink the tool.

What This Means For Build Week

For Build Week, the published judging language points to technical implementation, design and user experience, potential impact, and quality of the idea. That is a balanced matrix, not a single metric.

The practical takeaway for builders is this:

Do not hide the demo behind a long explanation.
Do not make the model choice ornamental.
Do not claim impact without a user.
Do not make judges guess what changed because Codex or the model was involved.
Do not confuse more features with a clearer project.

The best entries usually feel inevitable after you understand them. The problem is visible. The build responds to it. The demo proves something. The limitation is honest. The next step is obvious.

A Builder's Scorecard

Before submitting any AI hackathon project, I would score it with five questions:

Can a judge explain the project to someone else after one minute?
Does the demo show behavior, not only slides?
Is the AI component necessary to the result?
Is the target user clear?
Are the limits named honestly?

That scorecard does not guarantee a prize. It does something better: it makes the work legible.

And in a hackathon, legibility is not decoration. It is part of the build.

So here is the open question before the next winner list appears: what should count most in an AI hackathon: the idea, the execution, the impact, or the ability to explain the work clearly?

Sources

OpenAI Build Week: https://openai.com/build-week/
OpenAI Build Week on Devpost: https://openai.devpost.com/
OpenAI Build Week rules: https://openai.devpost.com/rules
OpenAI Open Model Hackathon community post: https://community.openai.com/t/open-model-hackathon/1334791
OpenAI Developers public post on RoboChef: https://x.com/OpenAIDevs/status/1983279855279190522

The New Developer Portfolio Is Not a Screenshot. It Is the Work Trace.

Jean-Sebastien Beaulieu — Fri, 24 Jul 2026 19:26:21 +0000

AI makes it dangerously easy to look productive.

A screenshot can look impressive. A demo can look polished. A generated article can read smoothly. A GitHub repository can have a clean README, a badge, a diagram, and a confident promise. But if I am trying to understand whether a developer can actually think, build, test, correct, and take responsibility, the final artifact is not enough anymore.

The final artifact shows what survived.

It does not always show what was refused.

That distinction is becoming central.

I am not writing this as someone who wants to hide AI. I use AI heavily. I use it to write, code, inspect, structure, argue with my own assumptions, and move faster through work that would otherwise stay trapped in my head. But the more I use it, the more convinced I become of one thing: the serious portfolio of the next few years will not be built from screenshots. It will be built from trace.

A work trace is the readable chain between intention and result.

It says: this was the problem, this was the plan, this is what changed, this is what failed, this is what I checked, this is what I refused to claim, and this is the final artifact I am willing to sign with my name.

That is where the developer becomes visible again.

The problem is not AI assistance. The problem is invisible judgment.

AI assistance is already part of developer work. Pretending otherwise is becoming less useful by the day. A developer can ask for boilerplate, refactor a function, generate a test plan, summarize a spec, draft a pull request, or compare design options. That does not automatically make the work fake.

The real question is sharper:

Did the developer understand what was generated?

Did they test it?

Did they inspect the weak assumptions?

Did they preserve secrets?

Did they know when to stop?

Did they make the final decision?

That is the line I care about. Not "was AI involved?" but "where did human responsibility enter the chain?"

Without trace, everything collapses into a flat surface. A demo looks like proof. A confident paragraph looks like expertise. A diagram looks like architecture. A passing screenshot looks like validation. But any serious builder knows that a result can be polished and still be empty. The work matters because of the decisions behind it.

I want portfolios that make those decisions inspectable.

DEV already points in the right direction

One detail in the DEV editor caught my attention: it supports Markdown, rich embeds, and visible guidance for embedding coding-agent sessions. I am not saying DEV officially endorses my portfolio method. That would be too strong. I am saying the writing surface itself shows where technical publishing is going.

Developer writing is no longer only final prose.

It can carry process.

It can carry code.

It can carry sessions.

It can carry evidence.

That matters because a developer article is often more useful when it shows the path, not only the conclusion. A polished tutorial may teach syntax, but a traced build teaches judgment. A traced build shows the ugly part: the wrong attempt, the correction, the boundary, the test, the reason a shortcut was rejected.

That is where trust begins.

The old portfolio model is too easy to fake

The classic portfolio pattern is familiar:

hero screenshot,
short project description,
technology badges,
repository link,
deployment link,
maybe a case study.

That structure still has value. I am not throwing it away. But it is weaker now because the cost of producing surface-level artifacts has collapsed.

A landing page can be generated.

A diagram can be generated.

A README can be generated.

A demo script can be generated.

Even a long explanation can be generated.

So the portfolio has to move one layer deeper. It has to show not only what was produced, but how the builder handled uncertainty.

For me, the strongest signal is not perfection. It is correction. Show me the place where the first plan was wrong and the builder changed course. Show me the test that failed. Show me the decision that protected the project from overclaiming. Show me the boundary that kept secrets out of public files. Show me the moment where the builder said: this looks good, but it is not proven yet.

That is not weakness. That is professional pressure.

A Work Trace Portfolio

Here is the model I want to use for my own work and recommend to other solo builders.

Every serious portfolio piece should have six blocks.

1. The problem

State the problem in plain language. Not the marketing version. The real version.

What was broken, confusing, slow, risky, missing, or worth testing?

If the problem is vague, the rest of the work becomes theatre. A strong problem statement is already proof of thought because it shows that the builder knows what they are trying to solve.

2. The plan

Show the plan before execution. It does not need to be long, but it needs to be concrete.

What files, systems, data, or interfaces were in scope?

What was out of scope?

What counted as success?

What would make the attempt fail?

This is where AI-assisted work becomes more honest. If a builder can show a plan and then show how execution followed or changed that plan, the reader gets a map instead of a magic trick.

3. The human decisions

List the decisions that mattered.

Not every prompt. Not every line of conversation. The decisions.

Why did you choose this implementation?

Why did you reject the shortcut?

Why did you keep the claim smaller?

Why did you use a simpler tool?

Why did you decide a result was not ready to publish?

This is the heart of the trace. The portfolio should not pretend that the AI was not there. It should show that the human remained responsible.

4. The work evidence

Show the material proof.

That can be a commit, a diff, a test output, a screenshot, a notebook, a source table, a design artifact, a validation report, or a short technical note. The format can change by project. The principle stays the same: give the reader something stronger than a claim.

For code, I like commit hashes, test commands, and minimal reproduction notes.

For writing, I like source registers, evidence boundaries, and correction notes.

For data work, I like the dataset source, transformation step, chart limitation, and what the chart is not allowed to prove.

The evidence does not need to be huge. It needs to be inspectable.

5. The correction log

This is the part most people hide.

I think it should become a strength.

What did you misunderstand at first?

What did the AI get wrong?

What did another reviewer catch?

What did you remove because it was too strong?

What did you postpone because the evidence was not ready?

In a world of generated confidence, visible correction is a credibility signal.

6. The final boundary

End each portfolio piece with a clear boundary.

What is demonstrated?

What is not demonstrated?

What would be needed to make the claim stronger?

What should the reader not assume?

This is especially important for AI-assisted work. If a builder says "prototype tested on a synthetic fixture," that is stronger than pretending it is a validated product. If a writer says "this is an informed opinion, not legal advice," that is stronger than dressing speculation as certainty.

Boundaries are not a loss of authority. They are how authority becomes trustworthy.

What not to publish

A work trace is not a raw dump.

Do not publish .env files.

Do not publish API keys.

Do not publish private emails.

Do not publish customer data.

Do not publish confidential prompts from a client or employer.

Do not publish credentials, tokens, logs with secrets, private identifiers, or material you do not have permission to share.

Traceability is not exhibitionism. It is disciplined evidence.

The goal is to show enough process to establish trust without exposing private material or turning the reader into a forensic investigator. A good trace is curated. It is honest, but it is not reckless.

Why this matters for solo developers

Large companies can buy reputation. They have brand gravity, hiring signals, conference slots, paid distribution, and institutional trust. A solo developer has to earn trust in public with smaller tools.

That is hard.

It is also possible.

A work trace lets a solo builder turn daily work into professional evidence. One article becomes more than a post. It becomes a proof object. One bug fix becomes more than a commit. It becomes a decision record. One prototype becomes more than a demo. It becomes a documented attempt with limits.

This matters for clients, employers, collaborators, and readers. If someone wants to know whether I can build responsibly with AI, I do not want to answer only with a polished homepage. I want to show the chain.

Here is the problem I saw.

Here is how I planned the work.

Here is where the AI helped.

Here is where I overruled it.

Here is what I tested.

Here is what failed.

Here is what I can claim.

Here is what I cannot claim yet.

That is a stronger portfolio than a gallery.

The developer skill is moving upward

This is the part I care about most.

AI does not remove the need for skill. It moves the skill.

Less time writing boilerplate.

More time deciding what should exist.

Less time memorizing syntax.

More time checking assumptions.

Less time formatting a first draft.

More time proving that the draft deserves to be public.

Less time producing the surface.

More time governing the meaning.

That is not a downgrade. That is a harder game.

The developer who wins in this environment will not be the person who can generate the most output. It will be the person who can turn generated output into responsible work. The person who can read the code, test the edge case, preserve the secret, name the uncertainty, and stop the article before it overclaims.

That is why the portfolio has to evolve.

My practical template

If I had to reduce this to a reusable DEV post template, I would use this:

## Problem
What was the real issue?

## Plan
What did I intend to do, and what was out of scope?

## Work Trace
What changed? What evidence can be inspected?

## Human Decisions
Where did I choose, reject, correct, or limit the AI-assisted work?

## Validation
What did I test, verify, review, or compare?

## Boundary
What is proven, what is not proven, and what comes next?

That template is simple enough to use every day and strong enough to separate a serious builder from a noise machine.

It does not require a giant report.

It requires discipline.

A live work trace for this article

This article should not escape its own rule.

Today, the work did not start as a clean essay. It started as a long planning thread, an active browser tab, a platform constraint, and a question: how do we write something related to yesterday's AI tooling article without repeating it?

The first decision was the boundary. This DEV post could not be a copy of the HackerNoon article. It had to keep the same intensity, but change the object. So the topic moved from usage limits to developer credibility. That decision matters because it prevented the easy path: rewrite the same argument, change a few paragraphs, and pretend it was original.

The second decision was the platform. DEV is not HackerNoon. DEV gives a Markdown editor, four tags, preview, cover guidance, embeds, and a developer audience that understands logs, diffs, tests, and traces. That changed the article. Instead of writing another polished opinion piece, the better move was to write a portfolio method that a developer can actually reuse.

The third decision was human responsibility. I did not want an article that says "AI helped me" like a confession or "AI built this" like a magic trick. I wanted the more useful sentence: AI assisted the work, but the human must keep the responsibility chain visible.

The fourth decision happened after the draft looked good. The article argued for work traces, but it did not contain one. That was the contradiction. At 15:19, after hours of planning, writing, checking, and previewing, the missing proof became obvious: if the thesis is real, the article itself needs a trace.

So here it is:

Problem: developer portfolios can look polished while hiding judgment.
Plan: write a DEV-native article about traceability, not another article about usage limits.
Work evidence: local draft package, metadata, sources, QA checklist, preview loaded in DEV, and tags selected one by one.
Human decisions: keep the article original, remove promotional drift, keep the claim practical, and add this trace before publication.
Validation: preview loaded, title visible, four DEV tags active, no publish action taken before review.
Boundary: this trace does not prove expertise by itself. It proves that the article follows its own method.

That is the point.

The day started with the impulse to write a complaint to OpenAI. It ended with two structured articles: one about human flow under AI usage pressure, and this one about the work trace that makes AI-assisted building credible. If that is not evidence for the argument, I do not know what is. The useful outcome was not the first emotion. The useful outcome was the transformation of that emotion into structure, publication, correction, and a better question.

A work trace does not need to be theatrical. It needs to be honest enough that the reader can see the chain between intention and artifact.

Final thought

I do not want a future where developers pretend they never used AI.

I also do not want a future where every generated artifact is treated like equivalent work.

The honest path is better: use the tools, show the trace, protect the private material, test the result, and sign only the claims you are willing to defend.

The new developer portfolio is not a screenshot.

It is the work trace.

If you were reviewing an AI-assisted developer portfolio, what would convince you more: the final demo, the code diff, the test log, or the planning trace that shows why each decision was made?

Sources and notes

DEV Editor Guide: https://dev.to/p/editor_guide
DEV Help, Writing, Editing and Scheduling: https://dev.to/help/writing-editing-scheduling
DEV post on embeds: https://dev.to/devteam/lesser-known-features-of-dev-embeds-3bpn
Current DEV editor observation, 2026-07-24: Markdown editor, up to 4 tags, cover image ratio guidance, and visible guidance for embedding coding-agent sessions.

The Data Lake Is Not the Problem. The Missing Admission Layer Is.

Jean-Sebastien Beaulieu — Fri, 24 Jul 2026 02:39:10 +0000

In 2024, the data problem stopped being only a storage problem.

It became a meaning problem.

That is the part I want to look at today: not the romance of "big data", not another vendor promise around lakehouses, not another generic AI infrastructure post. I want to look at the pressure entering the pipe: global data creation, datacenter power, cloud migration, data lake adoption, and the gap between what we store and what we can honestly interpret.

My position is simple:

The data lake is not the problem. The missing admission layer is.

We keep building larger places to put data. That is useful. But if the data arrives without provenance, quality state, contradiction handling, units, policy version, and claim boundaries, then the lake becomes a place where uncertainty goes to become invisible.

1. The world is producing data faster than institutions can govern it

Public estimates vary because "data created, captured, copied, and consumed" is not measured by one universal public counter. But the order of magnitude is clear.

IDC's Global DataSphere program tracks worldwide data created, captured, and replicated. Older IDC-linked reporting projected roughly 175 zettabytes by 2025, while newer secondary summaries place the global datasphere around 149 zettabytes in 2024 and about 181 zettabytes in 2025.

Those numbers should be read carefully. They are not the same as "curated data", "trusted data", or "query-ready data". Most data does not become clean evidence. A zettabyte estimate tells us about volume pressure. It does not tell us that the data is admissible for decision-making.

That distinction matters.

In a data lake, raw data, logs, model outputs, embeddings, tables, documents, images, and scientific artifacts can all coexist. This is powerful because storage is flexible. But flexibility creates a second-order problem: when everything can be stored, the hard question becomes what each object is allowed to support.

Can this record support a dashboard?

Can this model output support a claim?

Can this simulation result support a paper?

Can this benchmark support a product decision?

Can this old file be reused under a newer policy?

If the lake does not preserve those boundaries, the system may look rich while becoming epistemically poor.

2. The infrastructure cost is no longer abstract

The International Energy Agency estimated that data centres consumed around 415 TWh of electricity in 2024, about 1.5% of global electricity consumption. The same IEA page says data-centre electricity consumption grew at about 12% per year over the previous five years.

That is the physical side of the dataflow.

Every pipeline has a material footprint. It needs power, cooling, servers, network equipment, storage media, replication, monitoring, backups, and human operations. When AI workloads enter the loop, the data lake is no longer just a passive archive. It becomes part of an inference, retrieval, enrichment, and training ecosystem.

This does not mean "stop building data centers." That is not a serious answer. Hospitals, research labs, schools, security teams, public agencies, and scientific infrastructure all depend on computation.

But it does mean we should stop pretending that every retained byte has equal value.

A classification layer should ask:

Is this object raw, derived, validated, deprecated, contradicted, or suspended?
What policy admitted it?
What evidence is attached?
What claims are permitted?
What claims are forbidden?
What would make the object useful enough to keep?
What would make it safe enough to publish?

The energy problem and the governance problem are connected. If storage and compute are expensive, then useless ambiguity is expensive too.

3. The data lake market is growing because the pain is real

Commercial market estimates should not be treated like scientific measurements, but they are useful signals of enterprise pressure.

Grand View Research reported the global data lake market at USD 13.6 billion in 2023, with projections toward USD 59.9 billion by 2030 and a 23.8% CAGR from 2024 to 2030. Other market reports forecast strong growth in cloud data warehouses, warehouse-as-a-service, and multi-cloud data warehouse systems.

The exact numbers will vary by analyst, scope, and definition. The signal is consistent: organizations are spending heavily because the old split between operational databases, warehouses, lakes, and ML stores is under pressure.

Data is moving from:

batch reports to streaming signals;
clean tables to semi-structured and unstructured objects;
local warehouses to cloud-native storage;
human-only analysis to AI-assisted interpretation;
isolated datasets to reused enterprise memory.

That movement is not automatically bad. It is the reason modern analytics works. It is also the reason weak provenance spreads quickly.

When an object moves across systems, it can lose its original context. A file becomes a table. A table becomes an embedding. An embedding becomes a retrieval result. A retrieval result becomes a generated answer. A generated answer becomes a decision. If no admission policy travels with it, the claim can become stronger than the evidence.

4. A lakehouse improves architecture, but it does not solve meaning by itself

The lakehouse pattern exists because teams wanted the scale and flexibility of a data lake with more warehouse-like governance, metadata, schema control, performance, and transactionality.

That is useful. It is a real architectural improvement.

But a lakehouse still needs a higher-level question:

What is this data allowed to mean?

Schema tells us shape.

Metadata tells us context.

Lineage tells us movement.

Quality checks tell us whether a rule passed.

But claim governance asks something slightly different: what public or operational statement is allowed to be made from this object?

For normal business analytics, that might mean whether a metric can support a quarterly planning decision.

For AI systems, it might mean whether a generated answer can be shown to a user without a warning.

For scientific workflows, it might mean whether a computational result can support a paper, a material candidate, a classification, or only an internal hypothesis.

The lakehouse can help preserve structure. It does not automatically preserve epistemic discipline.

5. The real dataflow is not "source to dashboard"

The old mental model is too simple:

source -> pipeline -> warehouse -> dashboard

The modern dataflow is closer to:

source -> raw lake -> transformations -> features -> embeddings -> model context -> generated output -> review -> publication -> reuse

That is a longer chain. Every step can change meaning.

A unit can be dropped.

A timestamp can cross a timezone boundary.

A join can multiply rows.

A filter can silently remove failures.

A model can summarize uncertainty out of existence.

A dashboard can round away a warning.

A human can copy the strongest sentence and forget the caveat.

This is why I think data teams need a concept that sits between observability and publication: an admission layer.

Not every object should be admitted for every use.

Some should be admitted for storage but suspended for claims.

Some should be admitted for internal exploration but blocked from external publication.

Some should be admitted for narrow claims but rejected for broader ones.

Some should expire unless refreshed by new evidence.

This is not bureaucracy. It is data hygiene at the level of meaning.

6. What changed from 2024 to now

From 2024 onward, three pressures became harder to ignore.

First, AI made interpretation cheaper. That sounds good, but cheap interpretation creates more opportunities to over-interpret. A model can produce a convincing summary faster than a human can verify the lineage behind it.

Second, infrastructure pressure became visible. Data centres are no longer invisible rooms behind the internet. Their electricity, water, cooling, land, and grid requirements have become public-policy issues.

Third, enterprise architectures shifted toward more reusable data surfaces. Lakes, lakehouses, warehouses, vector stores, catalogs, and governance layers are no longer separate conversations. They are becoming one data operating system.

That convergence is exactly why classification matters now.

If data is reused more often, each reuse needs a memory of what the data was allowed to support before. If AI sits on top of the lake, the model needs more than retrieval. It needs evidence boundaries. If scientific workflows produce larger output sets, the publication layer needs to know what is admitted, suspended, and rejected.

7. The admission layer I want to see

The practical version does not need to be mystical.

It can start with simple fields:

source identity;
method and software version;
raw result reference;
unit map;
lineage hash;
quality score;
uncertainty state;
contradiction state;
policy version;
permitted claims;
forbidden claims;
decision state;
reason codes;
replay instructions.

Those fields do not solve science. They make the decision inspectable.

The most important output is not a beautiful score. The most important output is a boundary:

This can be used for X.

This cannot be used for Y.

This is suspended until Z is provided.

That boundary is what prevents a lake from becoming a machine that stores ambiguity and exports confidence.

8. What the statistics really say

The numbers do not prove that any one architecture is correct.

They prove that the pressure is real.

Global data volumes are in the zettabyte range. Data-centre electricity consumption is already a measurable part of global electricity use. The data lake and lakehouse markets are growing because organizations need flexible, large-scale data systems. AI is increasing the speed at which stored data becomes interpreted data.

The conclusion is not "panic."

The conclusion is "instrument the passage from data to claim."

If a system can store more, retrieve more, summarize more, and generate more, then it must also classify more carefully.

9. A better lake is not only bigger

A better lake is not only cheaper storage.

A better lake is not only faster queries.

A better lake is not only a new table format.

A better lake is a system where the data carries enough memory that future users can understand what it was, where it came from, how it changed, and what it is allowed to support.

That is the line I want to keep testing:

Data without provenance is not ready.

Data without uncertainty is not honest.

Data without claim boundaries is not safe to amplify.

The next data platform should not only help us ask, "What can we compute?"

It should help us ask, "What do we have the right to say?"

Sources

Related implementation work:
- Synthia: https://github.com/SeCuReDmE-main-dev/Synthia
- FNP-QNN-MVP: https://github.com/SeCuReDmE-main-dev/FNP-QNN-MVP
Related research note in French: https://www.academia.edu/170639397/Classifier_avant_damplifier_DMQC_comme_couche_dadmission_de_provenance_et_de_limitation_des_affirmations
Related research note in Spanish: https://www.academia.edu/170639576/Clasificar_antes_de_amplificar_DMQC_procedencia_y_admisi%C3%B3n_de_resultados_de_c%C3%A1lculo
ORCID: https://orcid.org/0009-0007-2904-0443
IEA, "Energy demand from AI" - data centre electricity consumption, 2024 estimate and growth context: https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai
IEA, "Data centres and data transmission networks" - latest findings page: https://www.iea.org/energy-system/buildings/data-centres-and-data-transmission-networks
IDC Global DataSphere program overview: https://my.idc.com/getdoc.jsp?containerId=IDC_P38353
Network World summary of IDC DataSphere forecast to 2025: https://www.networkworld.com/article/966746/idc-expect-175-zettabytes-of-data-worldwide-by-2025.html
Rivery summary of 2024 and 2025 global datasphere estimates: https://rivery.io/blog/big-data-statistics-how-much-data-is-there-in-the-world/
Grand View Research, global data lake market summary: https://www.grandviewresearch.com/industry-analysis/data-lake-market
ScienceDirect, "Data Lakehouse: A survey and experimental study": https://www.sciencedirect.com/science/article/pii/S0306437924001182

Validation Note

The global data volume numbers are directional estimates from market and analyst sources, not direct physical measurements. I treat them as scale signals, not exact truth. The IEA electricity figure is stronger for infrastructure context because it comes from an energy agency report. Market-size projections are used only to show adoption pressure, not to prove technical superiority.

Quebec Builders Can Build With the World: A Codex Hackathon Path That Preserves Contribution

Jean-Sebastien Beaulieu — Tue, 21 Jul 2026 19:59:57 +0000

I am writing this for builders, not as a complaint.

I recently built SecuredMe Education, a privacy-first education suite focused on verifiable learning, explicit consent, responsible AI adoption, and avoiding the publication of raw credentials or tokens.

The project was intended for OpenAI Build Week. Under the published rules, Quebec residents were excluded.

That disappointment matters, but the useful question is not “how do I get an exception?” It is:

How can future AI and Codex hackathons preserve contribution when prize eligibility is uncertain?

This article is not legal advice, not a demand for a retroactive exception, and not an accusation against organizers. It is a developer-facing proposal for better event design.

The technical problem behind the legal wording

Hackathon rules are often copied forward from older templates. That is understandable. Organizers are managing prizes, jurisdictions, sponsors, tax issues, privacy obligations, sanctions, platform risk, and review capacity.

But copied wording can become infrastructure. A line like “Canada excluding Quebec” may start as legal caution and later become an automatic gate that nobody revisits.

Quebec’s contest-publicity context changed in 2023. The RACJ describes the end of the former contest-publicity filing framework, while still making clear that this does not remove every legal or compliance obligation.

That distinction is important:

It does not prove that every hackathon must accept Quebec.
It does mean blanket exclusions deserve current review.
It also means participation and prize eligibility can be separated.

A simple access model

The way I model this is:

A = C x P x E / (U + R + T)

Where:

A is practical access.
C is clarity.
P is an available pathway.
E is evidence.
U is unresolved legal uncertainty.
R is unmanaged prize, privacy, or compliance risk.
T is template inertia.

The goal is not to force risk to zero. The goal is to reduce uncertainty enough that useful contribution is not erased.

Ten practical paths

Here are ten options hackathon organizers can use without pretending the risk does not exist.

Clarify whether a Quebec exclusion is based on current review or inherited template language.
Add a non-prize showcase track when prize administration is the blocker.
Allow conditional submissions while eligibility is reviewed.
Let Quebec builders waive prize eligibility while remaining visible.
Publish a Quebec addendum for the current RACJ context, Canadian contest basics, and privacy duties.
Provide an appeal or eligibility clarification channel before the submission deadline.
Create youth and education paths without monetary prizes.
Make privacy-first requirements explicit for learner-facing tools.
Add a rule-template linter that flags phrases like “Canada excluding Quebec”.
Create a public showcase for builders who cannot compete for prizes.

These are not radical changes. They are process states.

Developers already understand this pattern. When a system cannot safely execute one branch, we do not always delete the whole object. We mark state, isolate risk, continue review, and preserve traceability.

Why Codex belongs in this conversation

Codex is good at turning ambiguous process into reviewable artifacts:

source-backed checklists,
rule diffs,
eligibility matrices,
privacy review gates,
conditional submission states,
repeatable templates for future events.

That is why I opened a GitHub discussion in openai/codex. The idea is not to ask maintainers to decide the law. The idea is to ask whether future Codex-related hackathons could support tooling or event templates that preserve contribution even when prize eligibility needs separate review.

GitHub discussion:
https://github.com/openai/codex/discussions/34595

Project context

SecuredMe Education was built as a suite of privacy-first educational tools. The public project page is here:

https://devpost.com/software/securedme-education

Product hub:

https://securedme.ca/product/education/

Selected code context:

Scholarium: https://github.com/SeCuReDmE-main-dev/securedme-scholarium
Synthia: https://github.com/SeCuReDmE-main-dev/Synthia
QuaNThoR: https://github.com/SeCuReDmE-main-dev/QuaNThoR
FNP-QNN MVP: https://github.com/SeCuReDmE-main-dev/FNP-QNN-MVP
Algorithm Builder: https://github.com/SeCuReDmE-main-dev/algorithm-builder-app

Sources

OpenAI Build Week rules: https://openai.devpost.com/rules
Quebec eligibility clarification thread: https://openai.devpost.com/forum_topics/44448-quebec-eligibility-clarification
RACJ contest-publicity context: https://www.racj.gouv.qc.ca/actualiser-lencadrement-de-la-vente-et-de-la-fabrication-dalcool-et-mettre-fin-a-celui-des-concours-publicitaires/organisateur-de-concours-publicitaires

Closing

I am not fighting this only for myself. I am thinking about the next Quebec student, parent, teacher, or builder who wants to contribute to an AI education project and finds the door closed before the project is even reviewed.

Quebec can build with the world.

The practical next step is simple: clarify, modernize, and create at least one non-prize or conditional path that lets builders remain visible.