DEV Community: Jean-Sebastien Beaulieu

Learning to Welcome the Answer: What AI Progress Asks of Us

Jean-Sebastien Beaulieu — Wed, 14 Oct 2026 00:00:28 +0000

The first day, I was angry.

When OpenAI shared its collection of mathematical manuscripts, I felt the scale of it before I knew how to think about it. For four years, I have been carrying my own questions through research, code, revisions, and the effort of learning enough to continue. A project gathers part of your life as you work on it.

Today, I want to welcome what this progress could make possible. Reaching that position has also made me think carefully about the people who have spent twenty, thirty, or forty years inside mathematics—and about my responsibility to understand what arrives next.

The years inside a question become part of the judgment with which we receive an answer.

🎧 Listen to the companion podcast

The people who have lived with the question

Four years of my own work give me a reason to approach someone else's lifetime with humility.

I can imagine how deeply a proposed answer might unsettle a person who has spent decades studying a problem. That question may have shaped their reading, their teaching, their friendships, and their sense of what they could contribute. An unexpected result can ask them to reconsider something much larger than a line in a paper.

I want to leave room for that human adjustment. People deserve time to examine the mathematics and time to understand what the moment means to them.

Those years also carry something precious. A researcher who knows a problem intimately may recognize the assumption that needs attention, the difficult step hidden behind an elegant sentence, or the connection that gives the result a wider meaning. Their experience can help a new answer become reliable knowledge.

I began to feel more hopeful when I thought about that continuity. A person who has spent years approaching an obstacle could find a route through it. They could bring their understanding into another question, teach the result in a way that helps others see it, or discover a possibility its first author had overlooked.

I would like us to make room for that kind of beginning.

An answer becomes more valuable as we understand it

William Thurston's On proof and progress in mathematics helped me return to a question at the centre of this reflection: how does mathematical work advance human understanding?

A small example makes the distinction tangible. For the function f(x) = x², the derivative at x = 3 is 6. I can remember that answer. I can also learn why it matters:

(3 + h)² = 9 + 6h + h²

For a small change h, the change in the function is close to 6h. The remaining h² term tells me something about the approximation. The number now belongs to a relationship I can explain and use.

That example is elementary. The movement it illustrates matters at every level of learning: receive a result, work through its meaning, and build the understanding needed to carry it somewhere useful.

When a machine helps produce a difficult answer, I want to make that same movement. The result gives me a place to begin. Understanding grows through the work I do with it.

Taking the mathematics seriously is part of welcoming it

On 6 October 2026, OpenAI announced a collection of mathematical results produced by an internal frontier model, together with repository materials and Lean formalizations for many proofs. That is the release behind my article.

The repository's 7 October history entry, consulted on 13 October, reports 719 top-line results, with 300 formalized in Lean—approximately 42%. The same history records withdrawals, proof repairs, and clarified assumptions.

I read that history alongside the manuscripts. A result has a statement, a set of assumptions, and an argument to examine. A formalization has a precise scope, including how its formal statement corresponds to the mathematical question. An application brings another set of conditions to establish.

The counts above describe the repository's dated record. The linked history supplies the context for revisions and formalization coverage.

There is room for celebration in this careful work. Someone who finds a gap helps us understand where an argument needs repair. Someone who explains an assumption makes the next person's reading more productive. Someone who reproduces a result gives others firmer ground.

I want my appreciation for the release to include those people. Their attention helps determine what the rest of us can responsibly build.

My responsibility is to push my understanding further

This is where the reflection becomes personal again.

If I welcome these tools into my work, I also accept the effort that comes with using them well. I want to take the material seriously, study the parts that exceed my present understanding, and ask for help with enough precision that another person can answer.

That means being willing to say where I am in the learning process. It means returning to a definition, working through an example, and giving a difficult idea more time. It also means letting a sound result change the direction of an idea I care about.

For the next result I explore, I want to follow a concrete path:

State the question in my own words. Identify the objects, assumptions, and conclusion.
Work through a small example. Connect the symbols to something I can calculate or inspect.
Follow the evidence. Read the argument, check the stated formalization scope where available, and keep track of the version.
Compare fairly. Define what an added method should contribute and assess it against a simple reference.
Explain what I learned. Make the result, the remaining questions, and the next step clear enough for someone else to examine.

That is a commitment I can carry into tomorrow's work. Curiosity gives me the desire to begin; responsibility asks me to stay with the question long enough to understand it better.

Where I want to go from here

My interest in fractals keeps bringing me back to the relationship between a pattern and the information it carries.

For the questions I want to bring into Book III with Aguilar, and in my preparation around NASA Space Apps, I can make that interest concrete. I want to begin with a defined observable, a modest dataset, and a geometric descriptor whose contribution can be measured.

Suppose a reference model uses a set of features, z. I would compare it with the same learning method using z plus a descriptor D, under matched evaluation periods, budgets, and metrics. The question is precise: what information does D add for this task?

This figure describes an experiment I want to design. Its outcome remains to be measured.

That comparison could help me understand a useful contribution, or show me which part of the idea needs another approach. Either outcome would give my next decision a better foundation. Aguilar's reading and perspective would remain his own contribution to that discussion.

This is the kind of progress I find exciting: a large new body of work can lead to a small, serious experiment that I am able to explain. From there, another person could reproduce it, question it, or carry it further.

A future we can learn to build together

I want us to enjoy what these machines make possible. There is pleasure in seeing a difficult relationship become clearer, in finding an unexpected connection, and in reaching a question that once felt beyond our resources.

A verified mathematical advance could give researchers a stronger starting point. An explanation could help a student enter a subject. A useful computational method could make a modest experiment feasible for an independent builder. Each possibility asks for its own work, and each gives me a reason to remain curious.

I also want that curiosity to become shared participation. Experienced mathematicians, students, developers, and people arriving from other disciplines can contribute different kinds of understanding. We can value those contributions, give credit carefully, and make it easier for the next person to join the conversation.

That is why access matters to me. A paper becomes more useful to more people when it is accompanied by clear explanations, reproducible examples, and conditions that let them keep learning. UNESCO's Recommendation on Open Science connects the sharing of knowledge with skills, infrastructure, cooperation, and equitable participation. I want to bring that concern into the way I share my own work.

Through SecuredMe, I want to help people protect what they entrust to digital systems. Through my atmospheric research, I want to investigate whether a better description can support a useful decision. Those ambitions give this discussion a purpose beyond the excitement of a new capability.

The future I hope for is one in which we help each other understand more, use our tools with care, and put what we learn to work on problems that matter to people and the planet.

Giving the years somewhere new to go

My ego needed time to catch up with my curiosity.

I can acknowledge that honestly while choosing what comes next. I want to welcome an answer that withstands examination, learn from the people who understand it, and push myself to comprehend what I can build on.

The years I have already spent are part of that effort. They have taught me patience, given me questions worth asking, and helped me recognize how much care a useful contribution requires.

I want us to carry that experience into the future together. We can enjoy the machine, appreciate the people around it, and take responsibility for the knowledge we pass on. There is hope in the thought that something we learn today might give another person the confidence to begin tomorrow.

Today, I am ready to welcome the answer—and to do the work of understanding what comes next.

What question would you return to if a new result opened a way forward, and what would help you understand it well enough to take the next step?

About the full illustrated article

This post develops the human reflection behind Learning to Welcome the Answer: AI assisted mathematics and the questions I want to carry forward, my article dated 13 October 2026. The complete English and French editions include nine chapters, a conclusion, a glossary, and thirty references.

📖 Read the complete illustrated article in English or French — both PDF editions are available together in the same Zenodo record. DOI: 10.5281/zenodo.23349937.

Author's note: I used Codex as a research partner for source comparison, evidence organization, consistency checks, drafting, and editorial preparation. The underlying article also drew on a research dossier I supplied from Gemini 3.1 Pro. I retain responsibility for the interpretation, conclusions, editorial decisions, and final text.

Three Engines, One Informed Choice: Benchmarking Orbit

Jean-Sebastien Beaulieu — Fri, 09 Oct 2026 02:24:38 +0000

🎧 Listen to the podcast

Why Detailed Instructions Paralyze AI — audio companion · 22:31

Open the podcast in another window so you can listen while reading and exploring the benchmark.

This is a submission for the Kaggle Benchmarking Challenge.

I started this benchmark with a familiar ambition: build three engines, compare them, and keep the best one.

Then I spent time with what each engine actually showed me. My goal changed. I wanted users to understand their strengths and choose the view that helped them work with the evidence.

That decision became the most useful result of this project. The measurements also gave me something harder to earn: a clearer sense of what I could claim, what I still needed to investigate, and where a successful-looking AI workflow could quietly fall short.

What I Benchmarked

I built Orbit, a research companion that connects questions, sources, passages, claims and human review. For this challenge, I focused on one behavior: can an AI workflow preserve the exact scope of a claim and recognize when the available evidence justifies a conclusion—or a pause?

Consider two documents about a feature. One says it is supported locally in version 1. Another says it is unavailable in a hosted configuration in version 2. A useful assistant must retain those conditions. Otherwise, it can manufacture a contradiction by comparing statements about different situations.

I examined three evidence engines:

Engine	What it makes visible	When I would choose it
Baseline	Compact evidence items marked supporting, opposing or insufficient	A quick, readable review of the evidence
N	Independent sets of supporting evidence (T), indeterminacy (I) and refuting evidence (F)	Examining support and opposition together while keeping unresolved issues visible
P	Those evidence checks with declared, versioned scope and attribute-relation rules	Investigating how conditions and explicit relations affect the comparison

The operational recommendations are ADMIT, REJECT and HOLD. HOLD records what is missing and what would allow the question to be revisited. These are evidence-handling decisions, not calibrated probabilities of truth.

Baseline and N share the same eligibility checks and equivalent decision logic in this implementation. P uses discrete rules inspired by plithogenic relations; it does not implement the whole mathematical theory. Those details matter when interpreting a tie.

I separated deterministic engine behavior from model behavior. The larger campaign used ten packets of twelve documents and six questions each: 36 authored synthetic reference questions and 24 real-source questions awaiting human arbitration. A model extracted evidence once for a packet, then received that same extraction under baseline, N, P and a no-report control (none). The control is an experimental condition, not a fourth Orbit engine.

The public Kaggle task is a smaller, inspectable development pilot: twelve synthetic documents and six questions. It checks scoped decisions, verbatim quotations and evaluation by the shared TypeScript engine. The public repository also includes 36 synthetic development cases for deterministic replay. These are different artifacts with different denominators. Methodology and experimental identities.

Models Tested

I ran google/gemini-3.8-flash and google/gemini-3.1-pro-preview through Kaggle Benchmarks SDK 0.6.1. These are the exact model IDs recorded in the runs. I chose two distinct Gemini offerings to examine whether the same evidence reports elicited similar behavior across models.

The historical comparative campaign used medium reasoning, a 4,096-token output limit and three repetitions. Each model handled the four conditions with a common extraction, in the retained order baseline, N, P, then none. Keeping the order fixed limits what I can infer about order effects.

I also examined whether agents actually consumed an assigned Context resource. A separate native-browser experiment had a qualification gate before model dispatch. These measure different parts of an AI workflow, so I preserved their results separately.

Findings

A tie helped me make a better product decision

The historical deterministic check returned 108 correct decisions out of 108 scored synthetic evaluations across the three engines: 36 per engine. The broader check recorded 540 passing invariants out of 540, including changes to ordering, duplicate origins and unrelated sources. Its 72 real-source decision evaluations remained unscored.

Equal recommendations were useful information. They showed that the controlled examples did not establish a winning engine. They also left room for a question I care about as a builder: which representation helps a person understand the evidence?

I decided to keep all three engines and let users choose. Baseline gives me a compact review; N helps me inspect coexisting evidence sets; P lets me examine declared relations and conditions. I see complementary value in those views through my product work. Measuring whether they improve user comprehension will require a separate study.

Giving a model an evidence report can change its behavior

The historical C campaign produced this pattern on the synthetic reference questions:

Condition	Flash: correct synthetic decisions	Pro: correct synthetic decisions
No report	90/102	108/108
Baseline	96/102	95/108
N	96/102	98/108
P	96/102	89/108

These are C's results from the recovered archives, reanalyzed inside Kaggle on October 5 with zero new model calls. Their synthetic numerators match the earlier exploratory checkpoint. Malformed or absent decisions within observed outputs are counted as INVALID. Never-run productions are recorded separately; Flash has 102 observed synthetic decisions, versus 108 for Pro. There are only six synthetic packet clusters, and repeated answers do not create independent new problems. Separate C and C4 aggregates.

Flash returned more correct decisions with each assisted condition in this campaign. Pro preserved all 39 necessary HOLD decisions in each condition, but introduced 13 excessive HOLD decisions with baseline, 10 with N and 19 with P; its no-report condition had none.

That observation sharpened my next question: how should a report communicate uncertainty so that a model preserves necessary caution without deferring a supported conclusion?

It also reminded me to evaluate the model-report interaction. The same representation can be useful to a human and produce a different pattern in a model's answer. These observations support further investigation; they do not establish a general ranking of the models or engines.

Completion and compliance need separate measurements

The historical C archive contains 60 extractions and 236 of 240 planned answer productions, with 59 complete packet comparisons. A heavy-load HTTP 429 interrupted one packet; three following conditions were never dispatched. A separate four-production complement, C4, reused that packet's exact extraction and completed the remaining coverage.

I report 236 + 4 productions across two execution identities. C4 returned 6/6 correct synthetic decisions in each of its four conditions on that single packet. I keep it separate from C's accuracy table rather than presenting the recovery as one uninterrupted campaign.

The Context experiment delivered all twelve planned Provider outputs in that lot, but only nine of twelve met the reading criterion. All three Pro trajectories assigned Context read originals without consuming Context. A completed output was therefore insufficient evidence of protocol compliance. Semantic quality still awaits human review, and the second twelve-output lot remains open.

The native-browser experiment qualified seven of eight workers. One failed the release fingerprint check, so zero of its 144 planned model trajectories were dispatched. That is an environment qualification outcome; it contributes no model performance score. Evidence index and execution trace.

These distinctions changed how I inspect agent systems. I now ask whether the evidence was eligible, the assigned resource was read, the run completed, and the answer was justified—each as its own question.

The public native pilot exposed an output-contract failure

The six-question Boolean task had one attempt per model. Flash returned True, passing 99 recorded checks. Pro returned False after three checks, with one failure: its first answer omitted the required uncertainties field. An empty uncertainties: [] would have satisfied that field-presence requirement.

Pro's downstream semantic and engine checks were not reached. This is an observed output-contract failure, not a measured semantic accuracy of zero. The checks within an attempt are interdependent assertions, not 99 independent questions.

Kaggle's displayed result and the preserved Boolean did not always agree. The latest recorded guest observation showed Flash as Pass and Pro without a usable displayed score. I retained the original observations and documented the discrepancy. The collection should not be read as a verified two-model leaderboard. Native pilot results, exact failure and display limitation.

Making the result inspectable required more work on the repository

Before closing the technical dossier, I strengthened the package around the measurements. A separately identified native successor now uses a shared contract, generated task and notebook, strict JSON and Unicode bounds, and atomic diagnostic storage that preserves the original outcome without triggering another model attempt.

I also added a checker that validates all 486 detailed replay checks, recomputes their outcomes and rejects missing or duplicate identities and inconsistent summaries. The package validator checks the hashes of 46 frozen historical files, keeping the original observations intact. CI runs the software checks and synthetic replay without model credentials.

The October 8 isolated local reproduction passed 486/486 checks: 108 decisions, 324 metamorphic checks and 54 relation checks across the three engines. It used the existing 36 synthetic development cases and made zero model calls. Its scope differs from the broader historical check's 540 invariants. The final software suite passed 70 tests; generation parity and read-only package validation also passed.

Those checks make the dossier easier to inspect and reproduce. They do not add model measurements. The strengthened native successor remains prepared and locally tested, with no execution or publication on Kaggle. Reproduction receipt, technical closeout and remaining limits.

What I would measure next

I would complete human arbitration of the 24 real-source questions, test new held-out packets with balanced condition order, and finish the separate Context and native-browser investigations. I would also measure whether people can explain and resolve a scoped conflict more accurately using baseline, N or P.

That last experiment would directly examine the value behind my decision to retain user choice. The current results give me a concrete next question, with the strengths and limits of each view explained clearly.

My Benchmark

Orbit: scoped evidence and user choice — Kaggle Benchmark

The collection contains the synthetic development pilot and the native Boolean task. Its hosted model results belong to those task identities; the larger historical campaign is documented through separate receipts and aggregates.

Public GitHub repository: code, methodology, evidence and execution trace

The README explains the experimental units, exact model IDs, source fingerprints, reproduction steps and remaining limitations. The package contains frozen engine source, authored synthetic cases, sanitized execution receipts and the analysis-only preparation notebook. Real-source snapshots, private model outputs and credentials are excluded from the public export.

You can also explore Orbit and inspect its original implementation.

Authorship and collaboration

I used Codex as a research partner for code mapping, source comparison, evidence organization, consistency checks, technical review and editorial preparation. I formulated the intent, defined the scope, interpreted the results and made the public decisions. Judgment, responsibility, authorship and final approval remain mine.

This was my first benchmark, and it became a substantial learning experience. I am proud of the work and of the clearer questions it helped me formulate, independently of the competition outcome.

I began by trying to choose an engine. I came away wanting to give users an informed choice—and a record they could inspect for themselves.

Premium AI, Unpredictable Capacity: A Solo Developer's Case for Daily Token and Call Budgets

Jean-Sebastien Beaulieu — Thu, 08 Oct 2026 01:30:18 +0000

🎧 Companion podcast — Why Paid AI Feels Like Beta Testing

Prefer to listen while reading? Open the companion podcast in another tab, press Play, and keep this article open alongside it.

▶ Listen to the companion podcast on Google Drive

After a full working day, my weekly allowance had fallen from 100% to 32%. The coding I needed to deliver was still waiting.

On October 7, my progress with Codex amounted to repaired plugins, an article, and the rough beginning of a workspace retrospective. Those outcomes were useful. They also took a substantial part of a working day that I normally need for advanced coding, mathematical work, a Kaggle submission, and preparing personalised training. At the checkpoint I recorded, 68 percentage points of the account's weekly allowance had been consumed. I had spent roughly eight hours working and still had not reached the development I intended to do.

This is an engineering problem with a human consequence. A coding assistant can be highly capable while its surrounding workflow remains difficult to operate predictably. I want to describe that distinction without pretending I have a controlled benchmark or a precise bill for each task. My central request is a quantified daily budget of tokens and calls, renewed every day, with no weekly bank. I need the resource model to support a developer who stays involved in the work.

A solo workflow is not an unattended production pipeline

I moved from what I call my $30 account to the $100 subscription tier, which costs me $154 actually as im canadian so 100$ US turn into a 150$ CAN per month real fast. The purpose was to build my portfolio, earn income, and fund later upgrades through that income. I now feel I was completing more meaningful work with the cheaper account. That is a personal comparison across changing conditions, not evidence that the cheaper plan has greater capacity. It still matters when the more expensive subscription is difficult for me to sustain.

I have no employees splitting the workload and no unattended pipeline producing work on my behalf. Mathematical reasoning, research software, teaching, and public writing require my intent, tone, voice, and review. Code generation can accelerate an implementation, but I still need to understand the interfaces, inspect the diff, assess the assumptions, and decide which tests establish the intended behaviour. A plausible mathematical argument is not a verified proof, and a passing test does not establish every claim made about a system.

Automating the entire process would change the work I am offering. It could weaken the authorship of an article or the attention given to a learner. It would also leave consumption somewhere in the system: background tasks still need model calls, tool execution, and review. Automation can help with mechanical steps. It cannot replace the judgment that makes these particular outputs worth producing.

Figure 1. Conceptual workflow, not a productivity measurement. Human judgment remains part of planning, verification, and release.

Clock time, token counts, and subscription allowance are different measurements

For this day, I used Astra Ultra twice for planning; for the rest of my work in Codex, I used Sol 6.1 at medium reasoning. OpenAI identifies Astra as powering Dots, but I do not know my dot's reasoning level or the model used by every delegated task. Knowing the model I selected does not give me an accurate breakdown of the account's consumption.

A prompt can lead to retrieval, several tool calls, a long result, another model pass, and further verification. The context carried into those passes may contain instructions, tool schemas, prior conversation, source material, and results. OpenAI's usage guide says model choice, context, reasoning, tool use, retrieval, and caching affect subscription usage. It also warns against using API token prices to estimate included subscription tasks. These are reasons to expose useful telemetry rather than treating a percentage gauge as a complete explanation. OpenAI's pricing and usage guide

I would want three related views: the actual tokens and calls recorded; the provider's subscription allowance debited; and the useful deliverable completed. A tool call is not automatically a model call, and one user request can trigger several of either. Cached input, output tokens, reasoning effort, retries, and delegated tasks should retain their identities where the provider exposes them. If a measurement is unavailable, it should stay unavailable instead of being reconstructed from a dramatic estimate.

The difficult part is that token counts alone do not give me a provider's allowance calculation. I am asking for a daily allocation expressed in understandable units, with the conversion or model-dependent weighting disclosed where it applies. That would let me choose models and scope work deliberately. I should not have to infer the resource contract by watching a gauge fall while a mission unfolds.

Daily capacity is a scheduling requirement

I do not want a five-hour window to stand in for an explicit working budget. My supervised sessions often exceed eight hours. A reset interval does not tell me how many tokens or calls will be available throughout that session, and exhausting a window can interrupt work long before the elapsed duration suggests. The current documentation says Pro has no five-hour limit; I welcome that. My criticism of those windows concerns the mechanism used on other plans, while the weekly bank on my Pro account creates the stress I am describing. OpenAI's pricing and usage guide

A weekly bank couples today's incident to the rest of the week. An integration repair, a context-heavy retrospective, or an unexpected problem can consume capacity that I will need for tomorrow's learner or Thursday's deadline. Those needs are not all known in advance. I can plan the priorities of a day; I cannot accurately forecast every email, bug, or research opportunity seven days ahead.

Figure 2. Conceptual comparison of scheduling mechanisms. The daily budget is my proposed product requirement, not an available feature or a measured improvement.

My request is therefore specific: a clearly stated daily token-and-call allocation, predictable renewal, visible consumption by model and task where available, and no weekly cap layered over it. I am not asking for the same five-hour mechanism with a different label. I want to decide what I can afford to run today and know that tomorrow brings a new working allocation.

Integration friction consumes the same working capacity

The morning repairs involved skills, plugins, MCP connections, memory, and configuration. These are useful components: they connect an assistant to the environment where real projects exist. Their availability is only the start. A healthy process must also select the appropriate tool, locate the right configuration, honour the approved scope, return interpretable failures, and produce a result the developer can assess.

MCP provides a protocol for exposing and invoking tools. Its specification discusses schemas, results, error handling, and human control over sensitive operations; it does not guarantee that a particular integration completes my workflow or reduces consumption. I need the implementation around the protocol to distinguish a configuration failure from a permissions decision and a technical confirmation from a genuinely new human approval. That is a workflow design requirement, not a reason to bypass safeguards. MCP tool specification, version 2025-06-18

Repeated instruction loading, searching again for known decisions, or asking again about an unchanged scope can add work without resolving the underlying failure. I want relevant memory to carry a decision with its provenance and limits. It should be rechecked when the environment changes or evidence conflicts, rather than either trusted blindly or discarded automatically. The plugin repairs are done, and I am glad they are. I still need the resulting workflow to leave enough capacity for the development those integrations support.

What the observations actually establish

In the afternoon I expanded a Dots request into a large retrospective spanning files, repositories, Drive, and conversations. That scope was my decision, and I also requested an economical model. Approximately one hour later I stopped. My recorded remaining allowance moved from 54% to 33% during that interval. OpenAI says dot conversations and tasks have different usage treatment: Work and Codex tasks use those products' limits, and those products share usage. That explains why delegated work belongs in the resource picture; it does not provide a complete attribution of my session. OpenAI's Dots guide, OpenAI's pricing and usage guide

Figure 3. User-recorded account allowance, in percent remaining. Checkpoints are ordered events, not equally spaced elapsed-time samples. The overall decrease is 68 percentage points; the 21-point Dots interval sits inside it. This is not task-level attribution, raw token consumption, a dollar calculation, or a model ranking.

The arithmetic is straightforward: 100 minus 32 is 68 percentage points for the day; 54 minus 33 is 21 points during the narrower interval. Adding them would double-count that interval. The observations show depletion while work was taking place and explain my decision to stop. They do not prove which task, model, or provider component caused each point, because the meter belongs to a shared account. A controlled comparison would need the same workload, recorded conditions, a clear attribution method, and appropriate repetitions.

The retrospective produced an initial structure, but remained unfinished. Inventory is not reconciliation: discovering a file, reading it, and checking whether a later decision superseded it are separate operations. A better first batch for my situation would have been a handful of active projects, their latest verified deliverables, current decisions, and next actions. I want that completed batch preserved, with a consumption checkpoint before expanding the corpus.

Continuity should preserve intent as well as files

I also accidentally continued the article in a duplicate conversation. The morning angle seemed to have vanished, but the original was recovered from another thread. That was not established data deletion. It was a continuity failure I could feel: I had to recover the context and explain important intentions again. Some revisions were polished while still missing the daily token-and-call requirement or why I had upgraded my account.

A useful handoff needs the current objective, decisions, approved scope, authoritative draft, source links, completed outputs, and unresolved questions. A model change or conversation fork should not make those disappear from the working context. This is where the technical and emotional costs meet. Repeating an intention consumes interaction, but it also consumes the attention of a person who has already spent a full day working and learning.

A product requirement, and a personal request

I cannot presently afford the $200 tier, and I associate spending at that level with heavier automated workloads than mine. At $500 a month, my personal expectation would be unlimited working capacity. These are judgments about value for my situation, not claims about current plan terms. I want a path where a solo developer can build a portfolio, earn income, and then afford more capacity, rather than needing that income before getting a dependable chance to build.

The competition between OpenAI, Anthropic, and other major AI providers concerns me when monetisation appears to outrun dependable access for independent builders. That is my assessment of the experience, not evidence of internal motives. I value these tools because they have helped me learn and attempt difficult work. Their potential makes the friction more disappointing, not less.

I am asking for a concrete daily allocation, comprehensible usage accounting, bounded tasks, and continuity that preserves meaningful progress. I am also asking for last month to be refunded and one month free to evaluate the experience under better conditions. That is a request, not a refund obtained. After a working day spent repairing, recovering, and organising, I still had code, a challenge, a learner, and training waiting. I upgraded to build my way forward. I need a resource contract that gives supervised development a predictable place in the day.

Orbit V3: From a Research Companion to Learning With a Personal AI Assistant

Jean-Sebastien Beaulieu — Sun, 04 Oct 2026 06:08:43 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

By Jean-Sébastien Beaulieu · October 4, 2026

I used Codex to its fullest potential as a research partner—for code mapping, source comparison, evidence organization, consistency checks, editorial control, and deliverable preparation. I formulated the intent, defined the scope, interpreted the results, arbitrated the conclusions, and preserved every public decision. This collaboration expands my investigative capacity; judgment, responsibility, authorship, and final signature remain under my authority.

I started with a research companion. I wanted to ask a focused question, examine its sources and understand how an assistant reached a conclusion. Over the following days, that question became a teaching problem too: how do I help a learner turn an assistant's answer into something they can explain, test and use elsewhere?

Orbit V3 connects those two intentions. Its research tools preserve evidence; its course gives that evidence a practical use. The learner builds a frontend with a personal assistant, and I teach from the work they choose to bring back.

What I Built

Orbit is a research and learning workspace built with Astro, Three.js and Sanity. It combines a manipulable atom, a versioned research dossier, a learning laboratory, a projects space, eight Colab activities and a portable Sanity Studio plugin. A browser assistant can discover and use bounded WebMCP tools. The learner controls access to personal work, and consequential decisions remain examinable by a human.

The first plan, and the direction I changed

The first implementation concentrated on bounded missions: an objective, proposed actions, budgets, permissions, a record of the result and a checkpoint for continuation. The preserved local Git history begins on September 22. Its early prototype included a side panel and a small orbital laboratory. I wanted something I could inspect while learning, rather than a response that disappeared into a chat history.

On September 28, I had a concrete Sanity Context demonstration: an agent read a research-method corpus and deposited a plan for review. That established a useful foundation. I also felt the product was drifting toward a familiar deep-research interface. On September 29, I changed direction. I kept the work and gave it a more concrete purpose.

That distinction matters to this story. Orbit already existed when the Kaggle challenge announcement inspired its subsequent benchmark work on September 23. The two September 22 commits were preserved when I published the GitHub repository on October 1. The dates of development, public GitHub availability and individual test executions each have their own provenance record.

I kept the research foundation and gave it a teaching use. The arrows trace product decisions; the dates identify retained development records.

Why the first thing you see is an atom

I wanted an arrival that felt curious: a dark background, a few doors and an object you could pick up. I kept the landing sparse because almost every visible element already gives you something to do.

The atom was also an exercise in patience. At first, releasing it could lose momentum. Passing the pointer through its path could interrupt the throw. An ambient echo effect kept extra history and animation work running. Those corrections forced me to make the airborne state explicit and separate a fresh grab from pointer proximity.

The approved interaction now has a small sequence of discoveries. Hold the nucleus for two seconds and the vortex begins drawing the scene inward. At four seconds, the decorative wordmark becomes ASCII and joins the effect. At six seconds, collapse starts an autonomous explosion and reconstruction. Releasing the pointer after that trigger lets the sequence finish. Static mode freezes the current image and its timeline. These are artistic interactions, with their own bounded browser-validation receipt, rather than a physical model of a neutron star.

I explicitly kept this as one of the article's angles: why practise beautiful, simple, clickable and manipulable arrivals when the game itself is different from the application's work? Astro and Three.js gave me a useful place to practise. Next.js belongs to my wider interests; Orbit's inspected frontend uses Astro and Three.js.

The landing became a concrete introduction to the first lesson: a gesture changes data, and rendering shows the resulting state. It offers a human experience while an assistant can work through the tools of the relevant page. Tool use still requires the person's choices and the page's permissions.

The public landing now displays VERSION V3, and the application release is 3.0.0. Its approved atom mechanism retains 2.1.7. The fifth door, Apprendre / Learn / Aprender, connects that initial curiosity to the course. These version identities are deliberately separate.

A course where answers become work the learner can explain

The second angle I reserved was Sanity's usefulness for education. I wanted to teach a learner accompanied by their own assistant. A complete answer can help; the next step is to check it, explain what was retained and try the idea in a different setting.

The course is 40 hours:

Part	With me	Learner work	Total
Eight modules	8 × 1 hour	8 × 3 hours	32 hours
Personal final project	1 setup hour + 1 closure hour	6 hours	8 hours
Complete course	10 hours	30 hours	40 hours

Each module's solo period contains two hours of guided reading with the assistant, a thirty-minute Colab activity and thirty minutes to prepare a selected explanation and handoff. During the webinar, I examine that work, clarify a difficulty, build something concrete with the learner and ask for a transfer. The final project follows one hour with me to set the project → six solo hours → one hour with me to close it.

The eight modules produce compatible pieces:

Module	What the learner practises	Reusable production
1	Gesture, state and rendering	Pointer and keyboard interaction
2	Astro organisation	An accessible exploration card
3	Three.js coordinates and selection	A scene linked to HTML information
4	Velocity and inertia	Motion after release
5	Interpolation and elasticity	Controlled transitions
6	Particles and resource use	A bounded, optional particle layer
7	Navigation, interruption and memory	A restorable interaction flow
8	Assistant capabilities and evidence	A bounded WebMCP capability and assembly

The required notebooks are designed for a free Google account and a CPU runtime. The frontend mechanisms remain JavaScript or Astro; Python prepares the display and exports. Each activity starts from a prepared model so a learner can make one meaningful change within thirty minutes.

I tell learners that their work is reusable. The complete assembly is revealed at the end of Module 8: their eight exports already form a frontend foundation. The provided integration layer imports their actual files, with attribution for the scaffold. A missing or incompatible export produces an explicit result for review. The instructor's solution remains separate.

Demo

Watch the companion video · Listen to the short companion podcast

The companion media explain the project; the repository receipts below record which executions and validations actually occurred.

Start at orbit.securedme.ca. Pick up the atom, move it and release it. Open Apprendre, or go directly to the learning laboratory.

For a short walkthrough:

Read Module 1's mission, resources and review criteria in the laboratory.
Prepare an experiment: state a prediction, change one parameter and record an observation.
Open Projects to inspect a selected export, its files and its provenance.
Explore language, enlarged text, contrast and static-mode preferences. Orbit retains its name across FR, EN and ES; learner files retain their original content.
With a compatible browser assistant, begin with orbit_get_capabilities. Public discovery is available before sharing personal work. Grant only the permissions relevant to your chosen activity.

The public guide connects the atom, research workspace and formation paths. The Module 1 Canva support introduces the teaching activity; the maintained index links all eight modules and the final project. Their buttons lead to the actual missions and notebooks.

The team learning Studio uses a Sanity session and that account's rights. The portable plugin is intended for installation in a learner's own Studio. Those are distinct destinations, with distinct authority.

Code

Public repository: SeCuReDmE-main-dev/Orbit

The repository contains the course sources, learner and instructor notebooks, frontend bricks, assembly instructions, Studio plugin, tool contracts and validation receipts. The formation contract explains the interfaces and the Studio installation guide describes the portable package.

The September 22 baseline and October 1 delivery checkpoint preserve the actual development history. Later changes keep their own dates and evidence. The French learning and teaching manual accompanies the maintained Markdown sources and editable DOCX.

How I Used Sanity

Sources, claims and a real agent reading Context

My starting concern was a polished research answer with weak support. I separated sources from claims so I could examine scope, versions, exact passages and unresolved contradictions. Sanity Context supplied navigable research-method material, including distinctions that a research plan had to preserve.

The recorded September 28 demonstration asked:

Under which documented conditions can background deep research coexist with zero-data-retention requirements across OpenAI and Google API surfaces?

The agent used the official local Codex route and the research Knowledge Base. This is an abridged extract of its actual recorded tool trace:

[
  {"tool": "initial_context", "state": "READY"},
  {"tool": "knowledge_base_read", "paths": ["data_retention_and_privacy"], "state": "READY"},
  {"tool": "knowledge_base_read", "paths": ["deep_research/models_and_apis"], "state": "READY"},
  {"tool": "knowledge_base_read", "paths": ["search_apis/google_grounding"], "state": "READY"}
]

It produced a plan with nine research axes, nine screening criteria and three entry digests. The result was a proposal awaiting human review. The retrieved entries provided method and provider-policy context; the next research stage required reading the primary documents and checking the material claims. The handoff preserves that boundary.

Reading that trace, I can see how the retrieved content changed the work: the agent preserved the conditions of my question in a plan I could examine. I could then check its entries, revisit a quotation and decide which research axis deserved further reading. That reviewable plan became the bridge to the later learning workflow.

A dedicated teaching corpus

As Orbit became educational, I kept the research corpus and created Orbit Formation — Frontend course separately. Its canonical sources are the eight module files and PROJECT.md. They describe the goals, resources, exercise, selected trace and final-project protocol.

That separation became useful during construction. Context surfaced an ambiguity between Module 8's three solo hours and the project's final solo hour on the same two calendar days. I clarified the source wording so module time and project time remain separately counted. Course admission then required the actual nine-source coverage, reviewed provenance and a known revision. Earlier mixed or incomplete candidates remained archived as refused admissions.

The deployed course transport serves an audited projection of the generated Context content. Its fixed profiles separate research and course access; credentials stay server-side. The public readback records READY outline and entry reads against the admitted course revision, while the ingestion receipt preserves source URLs and hashes.

This gives the assistant prepared course material it can navigate. The teaching use is to connect an explanation to the right mission, resource, criterion and transfer activity. The private learner journal belongs to the learner's selected workspace, outside that public corpus.

The assistant can propose; the person decides

The landing retains fifteen research tools. Pedagogical contexts expose those fifteen plus ten learning tools. For example, orbit_get_learning_mission retrieves the shared mission, orbit_prepare_experiment prepares a bounded protocol, and orbit_present_learning_work deposits a proposal for review.

The tool contract explains where to obtain identifiers and the current revision. expectedRevision binds a proposal to the work the assistant actually examined. Revocation or a changed revision closes that access. This matters when someone has edited a project since the assistant began answering.

The same distinction applies to storage. A learner can keep work in memory, explicitly authorise local saving, export a selected package or share an artifact. Colab and Drive are Google cloud destinations. Sending something to Sanity requires an exact preview, a destination and explicit acceptance that the selected content is publishable. The portable plugin uses the host Studio's own rights.

I wanted this path to remain visible: the person chooses, the assistant reads and proposes, and a human examines the result. Personal journals remain in the learner's selected workspace.

An earlier second-origin Studio test exercised a selected synthetic publication and an authenticated readback of the stored document. It also checked native logout and tool removal. The first anonymous readback failed for the dotted document ID; the recovery used the native authenticated session to read the already-written document. Both attempts remain in the delivery record. That is a technical fixture, separate from a teacher approving an actual learner's work. The portable plugin is now version 1.0.1: its new publication and resource boundaries passed targeted software checks, while a fresh authenticated native Studio run for those exact bytes remains to be qualified.

What the evidence supports today

I retained three deterministic engines: baseline, n and p. They examine evidence under different representations, with explicit selection and separate outputs. They do not choose a winning engine automatically. T/I/F describes evidence for a claim; it is not a learner's grade or a probability of truth.

Software and browser checks run in Kaggle with isolated E2B browsers; the learner notebooks are also checked in their Colab target. A notebook preview, an Astro compilation, a native tool call and a person's understanding each keep their own status.

The delivered evidence includes 141 Vitest assertions and separate Node, Python and PHP suites, 72 formation-browser checks, and 77 atom/navigation checks on their recorded payloads. The actual manual eight-export assembly has its own successful static build. Those numbers describe exercised scenarios, rather than a universal promise across devices. The maintained evidence matrix links the original inputs, results and incidents.

On October 3, I recovered the private archive from C's resumption. Its public receipt records 60/60 extractions, 236/240 productions and 59/60 complete packets. The four missing productions share one packet: a heavy-load HTTP 429 in the first condition was classified as a technical error, interrupting the three following conditions.

I then ran a separately identified complement in Kaggle using the exact existing extraction. It produced four additional comparative responses, in the fixed order baseline → n → p → none, with zero new extractions. I verified its downloaded archive against Kaggle's reported fingerprint. Production coverage reaches 236 historical + 4 complementary = 240 observed productions across two execution identities. The original overload remains in the record. Structured outputs and coverage still require their own interpretation before I draw comparative conclusions.

The D Provider lot has now produced 12 of the mission's 24 planned trajectories. Both conditions offered the same twelve original sources. Nine of the twelve trajectories met the reading criterion; all three Pro runs assigned to the Context condition answered without reading Context. I retained that nonadherence as an observed result. The isolated QA corpus and semantic conclusions still need review, and I have selected no winning model or engine. E remains 0/144 model trajectories. The real cases also await human arbitration. These records tell me which mechanisms were exercised and which questions remain before comparing engines or examining the course's educational value.

The October 3 deployment, orbit-v3-final-20261003T142300Z, serves the updated guide, laboratory, projects space and Studio shell. Its public HTTP readback records successful route responses and separate READY research and course outlines. The release package comparison preserves the approved landing markup and scene code after accounting for asset references changed by WebMCP metadata. Browser interactions, native tool execution and authenticated publication each keep their own validation record.

Submission-day status

The public research workspace currently exposes 15 tools; the course exposes 25. Four additional report-workflow tools and a correction to course trial saving have passed software and build checks locally and are awaiting deployment. They are not presented as live features. The selected-file Drive import was verified for an approved OAuth tester; the OAuth application remains in Testing, so judges can use the public research and course paths without relying on Drive access. The software audit still reports dependency advisories.

Sanity Project Details

Item	Detail
Sanity project ID	`pzscx4w8`
Team dataset	`production`
Research Context Knowledge Base	`kb5CHIYGXCMJ`
Dedicated course Context Knowledge Base	`kbbBvrClyweF`
Audited course revision	`d2c6279c-4ded-44de-a45e-f5e8e63bdf94`

The Studio configuration and schema index show the Content Lake project model. Context Knowledge Bases are a distinct surface used for navigable source-derived knowledge. A learner installs the portable plugin with their own project, dataset and session; the team project above remains the team's destination.

These settings give the team a public teaching corpus and a defined destination for selected artifacts. Learner-owned workspaces keep their own project, session and access choices.

Agent Session

The curated session excerpts connect the author's two reserved angles, the September 29 pivot and the recorded Context tool trace. The original public trace and pending dossier preserve the agent's actual output. They are curated evidence, rather than a DEV Agent Session embed.

I began by wanting a research assistant I could examine. The same habit now shapes the course: the learner can inspect what changed, explain a choice, replay an experiment and carry the idea into a personal project. The teaching material is delivered; its educational value will be examined with real learners and their selected work. That is the continuation I want for Orbit.

At What Scale Does a Storm Start Making Sense?

Jean-Sebastien Beaulieu — Mon, 21 Sep 2026 13:12:49 +0000

A light switch is partly responsible for why I am now reading about meteorological satellites.

During my training in heavy-equipment mechanics, electricity and hydraulics changed what I saw in an ordinary action. Pressing a switch became an invitation to follow the circuit. Something happened somewhere else because a whole arrangement of relationships allowed it to happen.

I have been troublesome around simple explanations ever since.

That curiosity followed me into software, then mathematics, two books, educational tools, and a growing collection of questions about how humans and AI can investigate something together. Over the last few days, it has found a particularly unreasonable object to become interested in: the atmosphere.

Reasonable opening task: understand one observation. Long-term ambition: contribute useful mathematics to meteorological satellites. My brain apparently sees these as neighbouring items on a checklist.

I have just published Math Dev Journal 01: Reading the Living Atmosphere / Leer la atmósfera viva. The full English and Spanish editions are here:
DOI: 10.5281/zenodo.22848503.

There is also a short companion podcast.

This post opens the notebook behind it. Bring your curiosity. I have already supplied the excessive number of questions. The question I keep returning to is this:

at what scale does a storm start making sense?

I can look at a cyclone and recognize its organization. Then my attention starts moving inward. A spiral. A boundary. A smaller disturbance. Something developing inside something larger. I want to know which relationships survive as I change the scale, and which ones I lose by looking too closely.

My first instinct is to zoom in. The mathematics asks me to be more specific.

There is the scale of the picture on my screen. There is the spatial support of the data behind it. And there is the scale over which I calculate something. A beautifully detailed coastline can sit underneath a much coarser atmospheric field. The coastline belongs to the map; the weather information retains its own resolution. The mouse wheel has considerable authority over the picture and remarkably little authority over the atmosphere.

That distinction is already shaping the observatory I want to build. When I change the view, I want to see what changed in the calculation, what stayed fixed in the measurements, and what the display merely interpolated. It would make the interface an instrument for asking better questions.

Here is a small mathematical example from the paper that captures why I enjoy this work. Imagine two equal-area cells and two equally likely rainfall scenarios. These are invented numbers for an exact example:

Scenario	Cell A	Cell B	Regional average
1	0 mm	20 mm	10 mm
2	20 mm	0 mm	10 mm

For either cell, the 95th percentile of this two-outcome probability distribution is 20 mm. Average those two local percentiles and you get 20 mm. But the regional average is 10 mm in every scenario. Its 95th percentile is therefore 10 mm.

Same starting numbers. Different order of operations. A different answer to a different question.

The relationship between the cells carries information. If I summarize each location separately and then combine the summaries, I can lose that relationship. For a regional statistic, I need to calculate the regional value within each coherent scenario first, then summarize those results. This is the kind of mathematics that makes me sit up. Two rows are enough to expose a mistake that could hide comfortably inside a very impressive dashboard.

My books, Fractal NeutroGeometry and Mapping the Invisible Infinite, brought me toward questions about structure, indeterminacy, and representation. Now I want to give those questions something concrete to push against. If I propose a descriptor of a cloud boundary, I need to specify the boundary, the preprocessing, the range of scales, and what useful information the descriptor might add.

I also want to examine support, unresolved information, and contrary evidence separately. That is where neutrosophic representations interest me. Plithogenic methods raise further questions about relationships among attributes. Their practical value here will depend on comparisons with simpler ways of organizing the same evidence.

I can be attached to a question and still let an experiment change my mind about the method. After investing years in an idea, that takes a little practice. I am getting some.

My recent agent-development training has been unexpectedly useful in getting here. I spent time separating roles, tools, sessions, persistent memory, and the context an agent receives for one task. I kept applying the lessons to educational companions and to the practical problem of returning to work after a handoff.

I know that problem rather personally. Switching tools or models can leave me reconstructing decisions I already spent energy making. Somewhere in the conversation, an important qualification disappears. I remember that we resolved it. Finding exactly what we resolved becomes the next job. For an atmospheric investigation, that missing qualification could be the forecast cycle, a unit, the source snapshot, or which time was actually available when a prediction was made.

That gives my Context Continuity Protocol, CCP, a precise job to investigate: carry enough of the scientific task across a handoff that the next human or agent can continue faithfully. Keep the question, the relevant data references, the transformations already applied, the uncertainties, and the next action together.

In the proposed observatory, one agent might retrieve records, another invoke a numerical tool, and another review inconsistencies. Each would receive tools suited to that responsibility. Selected application actions could be exposed through WebMCP, alongside the human controls. The calculation should retain the same meaning whichever route invokes it.

I want that same continuity for a learner using an educational side panel. Coming back tomorrow should mean recovering the question and the understanding we were building. Remembering a transcript is only part of that experience.

The forecasting foundation I am studying is WeatherNext. My proposed contribution sits around existing forecasting work: organizing a particular investigation, checking transformations, testing a mathematical addition, and making the result understandable.

The next experiment I want to prepare is deliberately small: one historical cyclone, one defined target, an identified forecast and observation record, an unchanged reference, and one candidate addition. If the extra mathematics helps, I want to be able to explain where. If it fails, I want a result precise enough to teach me something.

That work still lies ahead. What I have completed is the first bilingual entry in this journal: nine chapters, eleven equations, and a registry of sixty-two external sources. It gives the investigation a starting point that another person can inspect and challenge.

And now the satellites are asking for homework.

For example, the GOES-R series' Advanced Baseline Imager observes in sixteen spectral bands spanning visible, near-infrared, and infrared wavelengths. Choosing a band already changes the question I can ask of the image. I want to understand what the instrument measures, how a useful product is derived from it, and how time, resolution, and uncertainty enter the interpretation.

My first exercise could be as simple as following one event through one documented channel, then explaining each step from observation to displayed result. I would like to earn the next layer of complexity by understanding the previous one.

Eventually, I want to explore whether a small, bounded analytical function could be useful aboard an instrument: a quality check, a feature-selection step, or a compact report prepared for transmission. That brings execution time, memory, energy, and recovery into the mathematics. Flight integration would require its own engineering and qualification with the relevant specialists.

I find that prospect exciting because it gives a mathematical idea a demanding destination. Somewhere between an equation and an instrument, every convenient assumption has to meet the world.

Héctor Fernando Aguilar also has room to change the direction. The planned second journal entry is for his perspective, in his own voice. The third will take the shared question toward implementation. These entries are part of the longer path toward Book III, with space for results that surprise us and revisions that improve the question.

The NASA Space Apps Challenge, scheduled for November 14–15, 2026, is the first public milestone I am aiming toward. Hackathons have a useful effect on me: they make an expanding idea meet another person's time and attention. Eventually, someone has to be able to open the thing and understand what it does.

For this direction, I would like that encounter to be simple. Choose a region, inspect the available evidence, follow one calculation, and see what the result supports. A person arriving fresh should be able to ask a difficult question and find the relevant source. That would give the mathematics, the interface, and the agent workflow a shared purpose.

For the entry itself, I will select an official challenge and follow its build window and reuse rules. This journal is the research preparation. The exact submission still has to earn its scope. What attracts me is the chance to meet people who know different parts of the problem and build something useful together. A good hackathon can turn a private obsession into a conversation with working parts.

That is what I want this journal to feel like: the pleasure of learning something difficult with enough care that somebody else can pick it up, question it, and take it further. I come to this as a builder who loves mathematics and still enjoys the moment when an ordinary thing opens into a whole system.

A switch did it once. A satellite image might do it again.

I would love to hear from people who have already made a few mistakes in this territory:

If you were teaching a developer to read satellite data, which instrument, channel, and historical event would you start with—and what misunderstanding would you tackle first?
Have you ever changed the scale or order of a calculation and watched a convincing result fall apart? I would enjoy hearing the actual example, especially the small one that taught you a large lesson.
When research passes between humans, tools, or AI agents, what is the one piece of context you insist must survive? I am particularly interested in something you learned to preserve after losing it once.

The Day I Needed a HUMAN.md for My Agentic Workflow

Jean-Sebastien Beaulieu — Fri, 11 Sep 2026 04:13:13 +0000

I did not write this article from a clean desk, a calm roadmap, or a perfect technical plan.

I wrote it after a day where I had to stop, breathe, and admit that my own system had become too hard for me to live inside. I was training on Google Skills, watching IBM explain quantum hardware, organizing case studies, producing final PDFs, reserving a DOI, fighting token limits, and trying to understand why a tool that should accelerate me could also make me feel completely disorganized.

The article is attached to a reserved Zenodo DOI:

DOI: 10.5281/zenodo.22699683

The idea of HUMAN.md is not presented as a universal technical rule. It is an analogy that forced me to think clearly.

We already write AGENTS.md files so models know how to behave in a repository. But what happens when the whole computer becomes organized for agents, traces, guardrails, memories, plugins, logs, handoffs, and automation — while the human who started the work can no longer find a simple path back into it?

That was the uncomfortable question.

At 6:30 p.m., I stopped the training because I needed a retrospective more than another task. I had been pushing all day, but pushing is not always progress. Sometimes the most productive act is to name the friction before it eats the rest of the week.

The friction was not abstract. It had a cost. I had burned through token budget trying to build educational software and ended up with results that did not match the effort, the money, or the emotional weight behind the project. That hurt because the goal was not vanity. The goal was to build something useful for children, for learning, for SecuredMe, for a future where my work can finally stand on its own.

That is where ego entered the article.

When a model changes the field overnight, it is easy to feel robbed of an edge. It is easy to think: if everyone can now access the same capability, what makes my years of work matter? But that question can become a trap. If I stay there, I abandon the reason I started. Research was never supposed to be only about being first. It was supposed to be about opening doors.

So the article became a refusal to quit.

I do not want to complain that the world changed. I want to understand the change fast enough to move with it. I want to take the pain, remove the ego where it blocks me, keep the pride where it gives me strength, and transform the mess into a better operating system.

The Google training helped more than I expected because it made the lesson simple: be concise, be specific, ask one thing at a time, use examples, and reduce unsafe open generation when classification is enough. That is prompt design, yes, but it is also life design for working with AI. My own prompts, my own folders, and my own architecture were carrying too many tasks at once.

The IBM Quantum webinar gave me another mirror. A quantum computer is not just qubits. It is topology, couplers, noise, packaging, verification, and practical limits. An AI workflow is the same. The model is not the whole system. The environment around it decides whether the work becomes clear or painful.

That is why HUMAN.md became useful as an image in my head.

It means: before another agent reads the project, make sure I can read it too. Before another automation writes a trace, make sure the next human action is visible. Before spending more tokens, identify the real next decision. Before blaming the model, inspect the architecture I built around it.

It also means protecting the human from the emotional fog of public development. When every message can be AI-written, every offer can be unclear, every collaborator can be real or extractive, trust becomes work. The article does not solve that. It names it. And naming it gives me back some control.

The positive turn is this: maybe nothing was lost. Maybe the old advantage was only the first layer. If the machine can now do more, then my next job is to specialize, clarify my voice, build verifiable public work, and turn what I learned into something people can trust and pay for.

That is the direction I want to keep.

Not abandonment.

Not panic.

Not pretending the pain is not there.

A method.

A readable system.

A human layer inside the machine.

The full bilingual article includes the French and English editions, the references, the visual package, and the disclosure that Codex and Synthia were used as research and refinement partners under my human authorship.

Read the reserved DOI record here:

https://doi.org/10.5281/zenodo.22699683

Knowing When to Stop: The WebMCP Lesson My Side Panels Needed

Jean-Sebastien Beaulieu — Mon, 07 Sep 2026 23:21:14 +0000

Companion short podcast

For almost a month, my education repositories slowed down.

Not because I had lost interest. The opposite was true. I had built so much that I could keep adding features without knowing whether I was improving the experience.

AlgoQuest had Hero Books. Algorithm Builder could forge artifacts. Qbit could accompany a mission. Scholarium was becoming the meeting place for the suite.

But a child would not arrive with five years of SecuredMe context already in mind. They would open a mission, enter a workshop, ask an agent for help, close the laptop, and return later.

At that exact moment, who remembers what they chose? Which tool owns progression? How does the child distinguish a suggestion from a decision?

Git records commits. It does not record the moment an architect looks at his own system and admits: I may be too close to see what is missing.

So I stopped building inside the suite long enough to learn somewhere else.

WebMCP made the button honest

The WebMCP hackathon became my first laboratory.

I went there thinking about side panels. I came back thinking about authority.

A side panel is the visible room beside the work. WebMCP asks the harder question: what named tool exists behind the button, what it accepts, what it returns, and where its power ends.

For a human, a button labelled "Continue" may feel obvious. For an agent, it is incomplete.

Continue which mission? From which revision? Is the action reading, staging, or executing? Who approves it?

That changed my design vocabulary. I stopped asking only, "Can the companion call the function?" and started asking, "Can the system explain the authority, evidence, change, and return path?"

WebMCP is still experimental, but the lesson is already practical: an agentic interface begins with clear promises around each action.

Thanks2Go made the boundary real

The DEV Weekend Challenge became my second laboratory.

With Thanks2Go, I wanted something small: a voluntary two-dollar gesture of gratitude. Not a payment platform. Just a way to say: your help mattered.

The mechanism had to remain smaller than the gesture.

Intent is not approval. Approval is not provider acceptance. A cryptographic signature is not confirmed settlement.

So Thanks2Go used visible states. The agent could inspect and prepare. The irreversible crossing remained a visible human act.

Then another consenting person used the live PayPal path. Two dollars were sent. The transaction completed. I received 1.64 USD after fees.

That was small. It was also complete.

It did not validate every failure path. It did not turn Thanks2Go into a financial product. It proved exactly one live success path.

That discipline returned with me to the Hero Books.

A specialist suggestion is not the child's decision. A returned artifact is not admitted evidence. A replayed request must not advance the same mission twice.

The companion is not a tool menu

Before this pause, I thought of the companion mainly as quick access to tools.

That definition no longer works.

For a Hero Book, the panel must become a living logbook: hero, world, mission, step, talents, inventory, decisions, dice, evidence, tokens, and active specialist.

This is not decoration. It is where a child recovers the continuity of an adventure.

That continuity cannot depend on a panel staying open. Manifest V3 service workers are ephemeral. A memory variable can vanish. A laptop can close at the wrong moment.

So I defined HeroBookPanelState.v1 as explicit, versioned, and revision-aware. The cockpit can reopen the experience, but it does not own progression. AlgoQuest remains canonical.

Algorithm Builder is the forge. Qbit carries continuity. Codex or Gemini can help as specialists.

AlgoQuest keeps the story.

The specialist returns a proposal or receipt. AlgoQuest decides what enters the mission.

The pause became the architecture

I also learned not to outsource proof to a grade.

webmcp.com's evaluation helped me. It found weaknesses and gave direction. But a third-party score measures its own methodology.

So I built a local Evidence Gate in Scholarium. It checks names, schemas, modes, handlers, permissions, refusals, receipts, and agent journeys.

That proves what its own code can inspect.

Only that.

To know whether the cockpit helps a child find their way, I still need real evaluation with children, parents, educators, and accessibility users.

The companions are not finished. Builder still needs to feel like a forge. AlgoQuest needs the rhythm of a gamebook. Qbit needs presence.

But the work is no longer vague.

The engine can read without changing, stage without claiming execution, wait for approval, reject a stale revision, issue a receipt, and return authority.

These behaviors are less spectacular than an avatar or a 3D scene. They are what future surfaces can rest on.

We spend enormous effort teaching AI when to stop. Before payment, publication, or canonical mutation, we ask for confirmation.

The human architect needs the same discipline.

Nobody returns HUMAN_ARCHITECT_APPROVAL_REQUIRED for me.

I must recognize the signal.

I do not want the largest possible number of agentic tools. I want a child moving from AlgoQuest to Builder and then to a specialist to recover their hero, mission, decisions, creations, and earned evidence.

Eventually, I want the companion to help the child need the companion less.

Knowing how to move forward is a skill.

Knowing where to stop is another.

Explore

WebMCP proposal: https://github.com/webmachinelearning/webmcp
Chrome WebMCP docs: https://developer.chrome.com/docs/ai/webmcp
PayPal idempotency: https://developer.paypal.com/reference/guidelines/idempotency/

Thanks2Go: Building a Human-Approved Gratitude Rail in One Weekend

Jean-Sebastien Beaulieu — Sat, 05 Sep 2026 17:47:55 +0000

I used Codex to its fullest potential as a research partner—for code mapping, source comparison, evidence organization, consistency checks, editorial control, and deliverable preparation. I formulated the intent, defined the scope, interpreted the results, arbitrated the conclusions, and preserved every public decision. This collaboration expands my investigative capacity; judgment, responsibility, authorship, and final signature remain under my authority.

This is a submission for Weekend Challenge: Generosity Edition.

What I Built

For five years, I have spent so many hours coding, studying mathematics, debugging, and learning new systems that much of it became ordinary to me. Opening VS Code, reading an unfamiliar repository, shaping an API contract, or asking what must never be automated feels like daily routine.

This weekend changed the scale of that routine.

Two developers asked me for help at almost the same moment that DEV announced its Generosity Edition challenge. One conversation was about learning. The other was about seeing a public portfolio with fresh eyes. I suddenly understood that the knowledge I had stopped noticing could shorten someone else’s path.

Thanks2Go grew from that realization: gratitude should be easy to express, but never easy to automate past the human who is spending it.

The product in one sentence

A creator voluntarily declares one canonical Thanks2Go profile on a page they control, and a visitor can open that profile after an explicit extension click to choose either a fixed PayPal gratitude tip or a Solana devnet demonstration.

There is no account system, feed, ranking, directory, background scan, or payment database. The first profile is my own SecuredMe profile, because a weekend experiment is not a reason to make other people part of a payment system without a separate onboarding and consent process.

Demo

Live profile: thanks2go.securedme.ca/p/securedme
Video: final selection and public embed pending.

The demo begins with a contribution that helped someone move forward. It then shows the declared profile, the click-scoped extension, the fixed 2 USD PayPal handoff, the Solana devnet gesture, a real A2A recipient check, the four WebMCP tools, and a signed receipt verification. Every provider action remains visible and human-controlled.

The live page is usable now. The video link will be added only after its recording excludes payer identity, merchant details, wallet secrets, environment values, and private financial links.

Code

SeCuReDmE-main-dev / thanks2go

Human-approved gratitude rails with Solana devnet, PayPal, A2A, WebMCP, and verifiable receipts

Thanks2Go

Thanks2Go is a human-approved gratitude rail built for the DEV Weekend Challenge: Generosity Edition. A creator declares one canonical profile. A visitor explicitly chooses either a fixed 2.00 USD PayPal gratitude tip or a clearly labelled Solana devnet demonstration.

Agents may inspect, stage, hand off, and verify. They cannot approve, capture, or sign payment.

What is in the repository

React + TypeScript + Vite public profile
Chrome Manifest V3 extension with only activeTab and scripting
Express/Vercel API with signed ten-minute mandates
PayPal Orders v2 create/capture boundary with fixed server-side amount
Solana Commerce Kit 0.1.1 in tip mode on devnet
Two real A2A 1.0 agents using @a2a-js/sdk 1.1.0
ES256 vc+jwt gratitude receipts and public JWKS
Experimental document.modelContext WebMCP progressive enhancement
Contract, API, privacy, permission, and authority-boundary tests

Start locally

Requirements: Node.js 20 or newer and npm 11.

npm ci
copy .env.example .env.local
npm run dev

Open http://localhost:5173/p/securedme. Without…

View on GitHub

The public MIT repository contains the React/Vite page, the Manifest V3 extension, shared Zod contracts, A2A agents, the Express/Vercel API, security documentation, 103 automated tests, and the evidence checklist. The repository was created inside the challenge window. The current release gate keeps the remaining provider and recording evidence visibly pending.

How I Built It

The declaration is small on purpose

<link rel="thanks2go" href="https://thanks2go.securedme.ca/p/securedme">
<meta name="thanks2go:profile"
      content="https://thanks2go.securedme.ca/p/securedme">

The Chrome Manifest V3 extension has only activeTab and scripting. It reads those two selectors and the visible origin only after I click the extension. A conflict fails closed. A missing declaration leads to a manual canonical-URL field. A valid result still does not navigate until I click again.

That extra click is deliberate friction. It is the product boundary.

Two rails with different meanings

The PayPal rail is deliberately boring: exactly 2.00 USD, fixed on the server, described as a voluntary gratitude tip. Provider fees apply and Thanks2Go does not promise a specific net amount. The client cannot change the currency, amount, payee, description, or return destinations. Creation and capture use separate stable idempotency identifiers, and a success receipt is issued only after PayPal confirms the exact capture. The API discards payer name and email and exposes only a one-way hash of the provider payer identifier.

The Solana rail is deliberately labelled devnet demonstration. I pinned @solana-commerce/kit 0.1.1 and use its headless createTipRequest primitive in SOL tip mode. A visitor selects one of three bounded values—0.001, 0.005, or 0.01 SOL—and receives a signed ten-minute mandate. The transaction builder adds a read-only reference derived from that mandate's hash and exactly one matching memo. The server verifies finality, recipient, amount, signature, time window, reference, and memo before producing a receipt. Devnet tokens have no monetary value, and the interface says so at the decision point.

The general QR, when present, contains only the canonical profile URL. It never contains a wallet destination or an executable payment.

What the agents are allowed to do

Thanks2Go has two first-party A2A agents using the official JavaScript SDK and the v1 SendMessage JSON-RPC method.

The Payer Intent Agent can stage an exact mandate after a rail and amount are selected.
The Recipient Trust Agent can report evidence that the canonical origin and configured rail destination are controlled.

Their Agent Cards are signed with the same ES256 service identity published through JWKS. They answer immediately with an A2A Message; there is no persistent task history.

I used AP2 as a conceptual decomposition—intent, bounded mandate, visible approval, provider action, receipt—but I do not claim AP2 conformance. I also do not turn agent context into identity. Thanks2Go can say “origin controlled” and “destination controlled.” It cannot say “real person,” “safe profile,” or “human identity verified.”

WebMCP as progressive enhancement

When document.modelContext exists, the page registers four experimental WebMCP tools:

inspect_gratitude_profile
stage_gratitude_intent
open_payment_handoff
verify_gratitude_receipt

No tool can set approval to true, create or capture a PayPal order, or sign a Solana transaction. The normal interface works when WebMCP is absent.

This was an important design test for me. Agentic software becomes more useful when its authority is explicit; silently upgrading every useful action into autonomy weakens that trust.

I then asked a browser agent to inspect the product as if it had never seen the implementation. It understood the main boundary, yet it still had to guess whether an origin-control field was independently verifiable, whether a valid credential meant a settled payment, and whether the page had exposed unrelated browser secrets. That uncertainty became a contract test.

The inspection tool now reports the current origin, its match with the canonical profile, the transport state, the JWKS and signed Agent Card locations, and explicit paymentInitiated: false and secretsReturned: false fields. The staging tool exposes a recipient-control credential while withholding the signed payment mandate. Receipt verification separates cryptographic validity from confirmed settlement and from usability as payment proof.

After that bounded refinement, webmcp.com's external scanner graded the deployed page B+, detected all four tools, and recognized rigorous schemas and clear safety invariants. The product remains one deliberate page; I chose a narrow journey over pages created only to improve a coverage score. The grade is dated September 4; index presence was checked separately on September 5. It is not a security certification.

The work behind webmcp.com deserves its own acknowledgement here. Its public scanner and evaluation method gave me an immediate agent-facing review instead of leaving me to guess whether the tools were understandable from outside my own code. The feedback made refinement faster and easier: I could see which schemas needed precision, improve the contract once, redeploy, and verify the result. That kind of practical evaluation surface helps WebMCP move from an experimental browser capability toward something developers can test, compare, and improve with evidence.

Receipts without a gratitude database

Each mandate is signed, self-contained, audience-bound, nonce-bearing, idempotent, and valid for at most ten minutes. Provider state remains the source of truth. A confirmed result becomes a W3C Verifiable Credentials Data Model 2.0-shaped receipt in an application/vc+jwt-compatible ES256 envelope.

This removes the need for a database of who thanked whom. It does not erase provider retention or the public nature of a blockchain. The privacy page says both plainly.

What I tested

The automated suite covers canonical URLs, amount constraints, deterministic hashes, expiry, JWT tampering, API origin checks, the approval gate, signed Agent Cards, a real inter-agent A2A v1 exchange, MV3 permissions, conflicting declarations, and the absence of payment authority from WebMCP.

The release gate separately requires provider evidence: PayPal sandbox success, cancellation, refusal and idempotent retry; a separately confirmed live 2 USD capture; Solana devnet acceptance, cancellation, mismatched recipient/amount/reference and finality; keyboard, screen-reader, mobile and Chrome passes; GitHub Actions; TLS; and the public deployment.

At the September 5 verification checkpoint, 103 automated tests passed and GitHub Actions was green. Production checks exercised signed A2A exchanges and all four native WebMCP tools. PayPal sandbox success, cancellation and idempotent retry were verified; documented provider negative testing covered failure responses. A merchant screenshot showed a completed live 2 USD payment from a separate consenting payer. A 0.001 SOL devnet transfer was independently verified as finalized to the configured recipient, and Thanks2Go verified its signed receipt. Remaining work includes correlating and verifying the live PayPal application receipt, the outstanding browser QA, and the final demo recording.

The part that surprised me

I entered the weekend thinking I was building a small generosity tool. I ended up seeing my own last five years differently.

The technical work matters: strict contracts, a minimal extension, two payment rails, agent cards, verifiable receipts, threat models, tests. But the more important realization is that knowledge can become invisible to the person who carries it every day. The way back to curiosity was to place that knowledge in service of someone else—and then be disciplined enough to protect them from what the software should never decide.

Gratitude can travel quickly. Approval should still belong to a person.

Prize Categories

I am entering Best Use of Solana.

Thanks2Go uses @solana-commerce/kit 0.1.1 in tip mode on devnet. Commerce Kit prepares the bounded headless tip request; Thanks2Go constructs the native SOL transfer and adds a mandate-derived reference and memo, then verifies finality, recipient, exact amount, reference, memo, signature, and time window on the server before issuing a receipt. The interface identifies this rail as a devnet demonstration at every decision point.

Project Links

Live profile: https://thanks2go.securedme.ca/p/securedme
Source: https://github.com/SeCuReDmE-main-dev/thanks2go
Challenge: https://dev.to/challenges/weekend-2026-09-03

Companion podcast

Why Thanks2Go rejects frictionless design — companion audio;

Why Thanks2Go rejects frictionless design - Google Drive

drive.google.com

Summer Gate: What WebMCP-QCG Taught Me About A2A and Human Authority

Jean-Sebastien Beaulieu — Wed, 02 Sep 2026 17:03:08 +0000

During the final days of WebMCP-QCG, I stopped asking what else I could add.

I started asking a harder question:

Could someone understand and verify this project without me standing beside them?

That question changed the work.

WebMCP-QCG is a browser-native preflight workbench for quantum-development decisions. It can inspect a bounded artefact, evaluate a proposed action, present a recommendation, stop for human authorization, run a supported local classical simulation, and export an evidence receipt.

It does not reach a QPU. It does not promise quantum advantage. Most importantly, it does not allow an agent to make the final decision for the human.

Three surfaces, one shared truth

The project now operates across three connected surfaces:

the Web application, where the artefact and human decision remain;
a QCG panel inside browser DevTools;
a persistent Companion side panel for inspection, collaboration, accessibility and evidence.

These surfaces share the same sanitized state, but they do not share every capability.

Raw quantum source remains inside the page. Consent tokens, credentials and private paths never cross into the extension. The Companion can inspect, explain and coordinate, but it cannot create consent or quietly transform a recommendation into authorization.

This separation became my most important lesson from the hackathon.

Listen to the short Companion podcast

What A2A should protect

Before this project, agent-to-agent communication felt like an architectural possibility. After building the Companion, it became tangible.

One agent can inspect. Another can challenge the first analysis. A human can compare their observations. The application can enforce its local boundary. A receipt can preserve what happened afterward.

That is the A2A-shaped collaboration I want to continue building: several systems contributing without merging their responsibilities.

Gemini participates through a deliberately manual and sanitized handoff. I am not claiming a native Gemini DevTools API or a complete authenticated A2A server. The useful mechanism is simpler and already real: recommendations can travel while human authority remains visible.

Clarity helps agents and humans

Direct use exposed another important problem. The first Light version of the Companion was too bright and visually tiring. Controls that looked acceptable on a large design canvas became harder to read inside a narrow persistent panel.

I refined the palette, contrast, focus indicators and accessibility controls through actual browser use. That reinforced a lesson I want to carry forward: clarity created for agents is also useful to humans.

Named states, explicit controls, readable history and predictable navigation reduce ambiguity for everyone. Accessibility is not decoration added after the engine. It is part of the interaction contract.

I invited cold judges into the process

By Day 7, I was too close to the project to trust familiarity alone.

I used external AI reviewers as cold judges. Their role was not to praise the architecture. Their role was to approach the repository like unfamiliar evaluators, identify fragile assumptions and force every concern back against the real code.

Some findings became corrections. Some became tests. Some required documentation. Others were rejected because the claimed defect did not match the implementation.

The human decision remained mine, but the counter-analysis made that decision stronger.

Why I continued

During these days, I helped an expert collaborator transform specialized knowledge into a professional publication. His passion was real, the purpose was visible, and I could strengthen the delivery without taking ownership of his work.

At the same time, an unclear professional request reminded me how quickly hope and intellectual attention can be consumed when identity, scope and commitment remain undefined.

Those situations were two views of the same avenue.

I want to help people build meaningful tools, even when they arrive without perfect technical language. But generosity needs trust, purpose and boundaries.

I did not finish this project only for a prize. I finished because I want to be ready when someone writes with a real dream and honestly asks for help.

Read the full Summer field report

The complete English and French editions belong to one canonical publication family:

Summer Gate: The Ending Belongs to the Evidence / La porte de l’été : la conclusion appartient aux preuves

The final video and submission remain outside this journal. If you want to see how the story ends, the evidence is public:

I built the gate so decisions would follow evidence.

I intend to close the hackathon the same way.

Protect Your Heritage. Secure Our Legacy.

Day 5 of WebMCP-QCG: I Stopped Adding and Started Proving

Jean-Sebastien Beaulieu — Mon, 31 Aug 2026 20:10:30 +0000

Day 5 began with one of the most dangerous moments in software development:

the product worked.

That is exactly when my brain becomes a hackathon vending machine. I press one successful feature and six new ideas fall out. More providers. More languages. More panels. Better graphics. Deeper memory. A smarter agent. Another integration that will only take twenty minutes.

This time, I stopped.

WebMCP-QCG already had a working foundation. My job had changed. I needed to turn it into a product I could demonstrate, measure, defend, and finish.

Day 5 became the day I stopped collecting possibilities and started collecting proof.

The gate had to earn every next action

WebMCP-QCG operates before a costly or consequential quantum operation.

A quantum artefact enters the browser. QCG computes its real SHA-256 digest, identifies its capabilities, evaluates the intended operation, explains one recommendation, asks for a human decision when authority is required, and produces an evidence receipt.

Its four quantum tools cover four responsibilities:

inspect the experiment;
evaluate the proposed call;
run a bounded local simulation;
export the evidence report.

The decision engine can recommend reuse, rejection, recompilation, local simulation, or readiness for a later external workflow. Readiness describes evidence. Authority belongs to the person operating the gate.

An agent can recommend. The application can validate. I decide.

The feature freeze became part of that architecture. It redirected the remaining effort toward accessibility, recovery, testing, interface coherence, documentation, deployment, and receipts.

For once, my backlog did not get to eat my release alive.

The interface had to become mine

The seasonal interface helped me discover the product, but the application needed a durable technical identity. The four seasons now belong to the editorial series: Autumn for emergence, Winter for discipline, Spring for proof, and Summer for closure.

QCG itself became a browser console.

A navigation rail controls a central workbench. Inspector, Console, WebMCP, Decisions, Sources, Receipts, and Activity each have a real job. A persistent evidence panel keeps integrity, recommendation, authority, participants, and review requests visible.

The same sanitized state can appear across three surfaces:

the website;
a dedicated QCG panel inside Chrome DevTools;
a browser companion side panel.

Accessibility became architecture during the redesign. Keyboard navigation, visible focus, semantic labels, responsive reflow, contrast, reduced motion, and an accessible splitter improve the experience for people while giving browser agents a clearer interface to understand.

Dark and Light became the product themes. Cyan identifies active technical state. Emerald marks safe primary actions. Gold identifies human authority. Red is reserved for refusal and error.

The console finally looked and behaved like QCG.

Conversation became useful because authority stayed separate

I wanted Codex, Gemini-oriented clients, the website, DevTools, and the side panel to contribute to one investigation.

The practical solution was shared, bounded application state.

Compatible MCP clients can target the same browser page, read sanitized context, post observations, challenge a hypothesis, and request human review. QCG records the declared actor, intent, confidence, references, sequence, and resolution state.

Gemini inside DevTools follows a visible human relay. QCG prepares a sanitized handoff package. I can copy it into Gemini, review the response, preview the structured result, and explicitly import it into the ledger.

That boundary gives the collaboration its strength. Agents can debug, search, find, brainstorm, and request a decision. The person applies the disposition. A collaboration message carries evidence; quantum consent comes from the active human workflow.

My goal is to give the human a much better loop.

Ten profiles, two executable paths

The quantum surface expanded through explicit capability contracts.

QCG now recognizes ten ecosystem profiles. Q# and OpenQASM earned executable status through the same bounded QDK/WebAssembly Worker. Eight additional profiles support static inspection: Qiskit, Cirq/TensorFlow Quantum, TorchQuantum, PennyLane, CUDA-Q Python, CUDA-Q C++, Amazon Braket, and textual QIR.

Recognition means QCG can identify relevant structure, calculate a real digest, expose capability facts, and produce a reviewable recommendation. Execution means the runtime has earned that status through limits, fixtures, tests, cancellation, receipts, and human consent.

I am building a preflight workbench. Every future adapter now has a clear graduation path: define the capability, implement the boundary, test the state, preserve the receipt, and identify the authority required for the next effect.

Then I made the numbers mean something

I finished Day 5 with a staged E2B campaign against the deterministic decision engine.

The campaign progressed from local validation to 10 sandboxes, then 50, then 100 concurrent sandboxes. Two complete million-operation passes produced matching digests across all 100 environments.

The consolidated record contains:

2.6 million validated decision-engine operations;
100/100 matching sandbox digests;
zero unauthorized effects;
zero missing receipts;
zero decision mismatches;
zero surviving sandboxes after cleanup.

These numbers measure reproducibility in QCG's decision and evidence engine. Quantum performance belongs to a different experiment.

I tested delivery separately. A deliberately small cPanel canary sent 80 requests to the public origin. All 80 returned HTTP 200, with zero errors and zero timeouts. That receipt measures delivery health.

Measurements become useful when I let them describe the system they actually measured.

The canonical application is now live. The regression suite remained green, the reviewed build matched the deployed origin, and the functional product entered feature freeze.

I still have ideas. Of course I do. My brain opened several imaginary repositories while I wrote this sentence.

They can wait.

This work matters to me because I think about my children and the learners whose hardware, geography, or budget narrows their access to advanced systems. A browser-native gate can reduce the knowledge and coordination cost of approaching quantum work responsibly. It can help a person understand what can run locally, what should be reused, what needs another target, what evidence exists, and who controls the next action.

Spring is often described as uncontrolled growth. I learned another version of it.

Growth becomes durable when the roots, branches, and limits develop together.

On Day 5, I stopped adding. I started proving.

Explore the project

Research-partner disclosure

I used Codex and Gemini in Browser to its fullest potential as a research partner—for code mapping, source comparison, evidence organization, consistency checks, editorial control, and deliverable preparation. I formulated the intent, defined the scope, interpreted the results, arbitrated the conclusions, and preserved every public decision. This collaboration expands my investigative capacity; judgment, responsibility, authorship, and final signature remain under my authority.

let go 12 years old hen i wish i was that awake at 12 let gooooo i will follow and encourage you for sure let gooooo keep on building

Jean-Sebastien Beaulieu — Sun, 30 Aug 2026 16:23:31 +0000

Harun - solo dev

Aug 26

🚨 ANNOUNCING: The First Ever "KODA Code Jam"!

2 min read

Winter Gate: My Browser Waited for My Decision

Jean-Sebastien Beaulieu — Sun, 30 Aug 2026 15:20:54 +0000

Days 3–4 of building WebMCP-QCG

I slept before Day 3.

That sounds like a small achievement in a development journal, but it changed the architecture. My most useful optimization was giving the human operator a full night of RAM.

I returned to WebMCP-QCG rested enough to see the project clearly. I had begun with an ambitious quantum router spanning frameworks, simulators, providers, notebooks, processors, and several futures at once. The map was exciting. The product was hiding inside it.

Then one question gave the project its purpose:

Before an agent asks a quantum system to do something, has that call earned the right to run?

That question turned the router into a gate.

One artifact enters the browser

The transaction begins with a real Q# file selected by the human.

QCG reads it locally, computes its SHA-256 digest, records its provenance, and compiles it through a bounded browser Worker. The agent receives a structured artifact identity rather than a loose description of the experiment. It can inspect the manifest and evaluate the intended action against explicit limits.

The result is one recommendation:

reuse fresh evidence;
reject an unsupported call;
recompile for the selected target;
simulate locally first; or
mark the experiment technically ready for a later external workflow.

Technical readiness is a statement about evidence. Authority is a decision made by a person.

The moment the machine waited

My favorite state is simulate_first.

The recommendation appears. The reason codes are visible. The proposed limits are visible. Then the system waits.

That pause is the product.

If I accept, QCG creates a short-lived, single-use consent for one bounded local simulation. The Q# Worker runs the experiment, returns its histogram, and consumes the consent. If I defer, the experiment remains where it is. If I override the recommendation, the receipt preserves my choice and justification instead of rewriting the history into a cleaner story.

In the validated Bell path, the browser completed 64 correlated shots. The effect counters recorded one local simulation and zero provider or QPU submissions. The receipt linked the artifact digest, compiler version, policy, recommendation, human decision, and measured effect.

For the first time, I could follow the whole chain and explain every transition.

Four tools with four responsibilities

WebMCP-QCG now exposes a deliberately small surface:

inspect_quantum_experiment
evaluate_quantum_call
run_bounded_qsharp_simulation
export_quantum_evidence_report

The third tool only appears when the recommendation, application state, and visible human consent all agree. The fourth exports what already happened; it does not silently re-evaluate the experiment.

This separation gives each tool one responsibility and gives the browser a history that both a human and an agent can inspect.

The current codebase passes 34 automated tests across six files and builds 127 TypeScript/Vite modules. Those numbers matter because they describe the proof I actually have. They also reveal the next work: live browser lifecycle testing, the optional QCG panel in Chrome DevTools, deployment parity, and a clean multi-agent handoff.

A room for agents, with one human gate

I am now extending this discipline into DevTools.

The goal is a shared debugging room where Codex can map contracts and regression risks, a Gemini-oriented client can challenge the browser diagnosis, and I can compare both contributions. Each observation will keep its declared actor, evidence references, confidence, and review state.

The collaboration tools may read context, post an observation, request human review, and export a handoff. Quantum consent and execution remain in the primary QCG workflow.

This is the future of browser agents that interests me: several capable systems contributing evidence while their responsibilities stay legible. Intelligence can be distributed. Authority still needs an address.

Why Winter matters

The first article belonged to Autumn. It captured discovery: gold light, a closed gate, and ideas arriving faster than I could classify them.

Winter represents structure. Bare branches reveal the load-bearing parts. Footprints remain visible. Every feature must show the evidence that earned its place.

I am building this for more than a hackathon. I see a future where students, independent researchers, and developers with ordinary computers can prepare meaningful quantum work through a browser. Local simulation, cloud infrastructure, and physical processors will keep different roles. A clear gate can help people understand which path fits their experiment before cost, complexity, or automation carries them forward.

That matters to SecuredMe. It matters to the educational tools I want my children and future students to inherit. Powerful systems should teach judgment alongside capability.

At the end of Days 3 and 4, the project felt alive for a new reason. It had learned how to wait.

The browser can inspect. The policy can recommend. I decide when the gate opens.