DEV Community: Jean-Sebastien Beaulieu

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

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

AI makes it dangerously easy to look productive.

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

The final artifact shows what survived.

It does not always show what was refused.

That distinction is becoming central.

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

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

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

That is where the developer becomes visible again.

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

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

The real question is sharper:

Did the developer understand what was generated?

Did they test it?

Did they inspect the weak assumptions?

Did they preserve secrets?

Did they know when to stop?

Did they make the final decision?

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

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

I want portfolios that make those decisions inspectable.

DEV already points in the right direction

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

Developer writing is no longer only final prose.

It can carry process.

It can carry code.

It can carry sessions.

It can carry evidence.

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

That is where trust begins.

The old portfolio model is too easy to fake

The classic portfolio pattern is familiar:

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

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

A landing page can be generated.

A diagram can be generated.

A README can be generated.

A demo script can be generated.

Even a long explanation can be generated.

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

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

That is not weakness. That is professional pressure.

A Work Trace Portfolio

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

Every serious portfolio piece should have six blocks.

1. The problem

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

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

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

2. The plan

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

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

What was out of scope?

What counted as success?

What would make the attempt fail?

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

3. The human decisions

List the decisions that mattered.

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

Why did you choose this implementation?

Why did you reject the shortcut?

Why did you keep the claim smaller?

Why did you use a simpler tool?

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

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

4. The work evidence

Show the material proof.

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

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

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

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

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

5. The correction log

This is the part most people hide.

I think it should become a strength.

What did you misunderstand at first?

What did the AI get wrong?

What did another reviewer catch?

What did you remove because it was too strong?

What did you postpone because the evidence was not ready?

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

6. The final boundary

End each portfolio piece with a clear boundary.

What is demonstrated?

What is not demonstrated?

What would be needed to make the claim stronger?

What should the reader not assume?

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

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

What not to publish

A work trace is not a raw dump.

Do not publish .env files.

Do not publish API keys.

Do not publish private emails.

Do not publish customer data.

Do not publish confidential prompts from a client or employer.

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

Traceability is not exhibitionism. It is disciplined evidence.

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

Why this matters for solo developers

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

That is hard.

It is also possible.

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

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

Here is the problem I saw.

Here is how I planned the work.

Here is where the AI helped.

Here is where I overruled it.

Here is what I tested.

Here is what failed.

Here is what I can claim.

Here is what I cannot claim yet.

That is a stronger portfolio than a gallery.

The developer skill is moving upward

This is the part I care about most.

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

Less time writing boilerplate.

More time deciding what should exist.

Less time memorizing syntax.

More time checking assumptions.

Less time formatting a first draft.

More time proving that the draft deserves to be public.

Less time producing the surface.

More time governing the meaning.

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

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

That is why the portfolio has to evolve.

My practical template

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

## Problem
What was the real issue?

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

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

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

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

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

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

It does not require a giant report.

It requires discipline.

A live work trace for this article

This article should not escape its own rule.

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

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

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

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

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

So here it is:

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

That is the point.

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

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

Final thought

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

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

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

The new developer portfolio is not a screenshot.

It is the work trace.

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

Sources and notes

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

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

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

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

It became a meaning problem.

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

My position is simple:

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

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

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

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

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

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

That distinction matters.

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

Can this record support a dashboard?

Can this model output support a claim?

Can this simulation result support a paper?

Can this benchmark support a product decision?

Can this old file be reused under a newer policy?

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

2. The infrastructure cost is no longer abstract

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

That is the physical side of the dataflow.

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

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

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

A classification layer should ask:

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

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

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

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

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

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

Data is moving from:

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

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

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

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

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

That is useful. It is a real architectural improvement.

But a lakehouse still needs a higher-level question:

What is this data allowed to mean?

Schema tells us shape.

Metadata tells us context.

Lineage tells us movement.

Quality checks tell us whether a rule passed.

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

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

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

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

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

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

The old mental model is too simple:

source -> pipeline -> warehouse -> dashboard

The modern dataflow is closer to:

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

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

A unit can be dropped.

A timestamp can cross a timezone boundary.

A join can multiply rows.

A filter can silently remove failures.

A model can summarize uncertainty out of existence.

A dashboard can round away a warning.

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

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

Not every object should be admitted for every use.

Some should be admitted for storage but suspended for claims.

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

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

Some should expire unless refreshed by new evidence.

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

6. What changed from 2024 to now

From 2024 onward, three pressures became harder to ignore.

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

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

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

That convergence is exactly why classification matters now.

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

7. The admission layer I want to see

The practical version does not need to be mystical.

It can start with simple fields:

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

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

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

This can be used for X.

This cannot be used for Y.

This is suspended until Z is provided.

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

8. What the statistics really say

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

They prove that the pressure is real.

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

The conclusion is not "panic."

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

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

9. A better lake is not only bigger

A better lake is not only cheaper storage.

A better lake is not only faster queries.

A better lake is not only a new table format.

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

That is the line I want to keep testing:

Data without provenance is not ready.

Data without uncertainty is not honest.

Data without claim boundaries is not safe to amplify.

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

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

Sources

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

Validation Note

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

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

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

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

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

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

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

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

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

The technical problem behind the legal wording

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

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

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

That distinction is important:

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

A simple access model

The way I model this is:

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

Where:

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

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

Ten practical paths

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

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

These are not radical changes. They are process states.

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

Why Codex belongs in this conversation

Codex is good at turning ambiguous process into reviewable artifacts:

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

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

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

Project context

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

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

Product hub:

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

Selected code context:

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

Sources

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

Closing

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

Quebec can build with the world.

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