DEV Community: 🎓 Navid Ishaq

We Merged 3 Repositories Into 1. Then AI Said: Roll It All Back.

🎓 Navid Ishaq — Fri, 06 Nov 2026 11:37:01 +0000

We Merged 3 Repositories Into 1. Then AI Said: “Roll It All Back.”

Three repositories. Two Render services. One website. And a debugging lesson worth sharing.

We set out to simplify the architecture behind DeTLeng Case Studies, a production website featuring an AI analytics assistant and 100 verified BigQuery analytics tools.

The goal was not to rebuild a working website. It was to remove a fragile dependency without losing the work already done.

The Architecture: Before and After

BEFORE                               AFTER
────────────────────────────         ────────────────────────────
 GitHub Pages Website                 GitHub Pages Website
          │                                     │
          ▼                                     ▼
 FastAPI Chatbot (Render)             Unified FastAPI (Render)
          │                                     │
          ▼                                     ▼
 Remote MCP Service (Render)          100 Allow-Listed Python Tools
          │                                     │
          ▼                                     ▼
     Google BigQuery                        Google BigQuery

 2 backend services                    1 backend service
 Remote MCP session                    Direct Python calls
 Cold-start dependency                 No second service to wake

Engineering concern	Before	After
Runtime services	Two Render backends	One unified backend
Analytics execution	Remote MCP session	Direct, registered Python calls
Cold-start behavior	Second service could stall	Single-service recovery and bounded retries
Data access	Verified BigQuery tools	Same allow-listed, read-only tools
Website	Existing GitHub Pages site	Existing design and URLs preserved

The integration brought together the static website, the FastAPI chatbot, and the verified analytics tools. Local tests passed, the consolidated repository was pushed, and then GitHub displayed a red ❌.

The Advice That Almost Undid the Migration

The AI assistant's suggestion was simple: roll everything back.

After all that integration work?

I couldn't resist asking: “People at the office ask who hired me. Now I have to ask—who made you an AI?” 😄

But the joke exposed an important engineering distinction:

A failed check is a request for evidence, not an automatic instruction to reverse an architecture.

Rollback can be the correct response to a live incident. Here, however, the failure was in CI, and we had not yet established that production was broken.

The Root Cause Was One Boolean Condition

The warmup cache started with an empty timestamp:

_warm_ok = 0

The original condition was:

if time.monotonic() - _warm_ok < WARM_TTL:

On a freshly started GitHub Actions runner, monotonic uptime could still be below the cache TTL. The application therefore treated zero as if a successful warmup had occurred.

Two CI tests failed. The targeted correction was:

if _warm_ok and time.monotonic() - _warm_ok < WARM_TTL:

One guard condition. Not a three-repository rollback.

The fix passed local tests, and the next GitHub Actions run went green. We then deployed the unified Render backend, configured Google Cloud access, updated the website's API URL, and obtained live analytics responses for executive, sales, customer, delivery, and payment summaries.

That was functional validation—not a claim that every cold-start scenario or all 100 tasks had already been exhaustively tested.

What AI-Assisted Engineering Should Learn

Before recommending a destructive reversal, an assistant should help establish:

Scope: Is this a CI failure, deployment failure, or live customer incident?
Evidence: Which exact test, log, or request failed?
Reproduction: Can we explain the failure deterministically?
Smallest safe fix: Can we correct the defect while preserving working code?
Rollback threshold: Is there actual production risk that justifies reversal?

AI can accelerate implementation. But its real value is measured by judgment under uncertainty, not by how quickly it proposes the most dramatic command.

Don't let an AI turn a debugging problem into a demolition project.

Explore the Project

🌐 Live case-study website: casestudy.detleng.com
📊 100 Analytics AI Tasks: Explore the tasks
💻 GitHub repository: Navid-Ishaq/detleng-case-studies

Have you ever been advised to roll back something that only needed a small fix? Share the diagnosis—not just the disaster.

About the Author

Muhammad Naveed Ishaque is a multidisciplinary thinker, educator, and founder of the DeTLeng Ecosystem, exploring AI, data, technology, business, and human-centered innovation through continuous learning and practical research.

🌐 Explore DeTLeng: www.detleng.com

The Most Dangerous Bug in AI Isn't in the Code. It's in Our Definition of Winning.

🎓 Navid Ishaq — Thu, 05 Nov 2026 10:22:29 +0000

What if the greatest threat isn't AI becoming too powerful, but humanity forgetting when to stop giving it more power?

Editorial Note | Purpose & Perspective

This article is not intended to create fear about AI or discourage technological innovation. Its purpose is to encourage responsible development, human safety, transparency, and accountability, supported by credible evidence and expert perspectives.

Our central question: What should responsible developers do today to prevent tomorrow's warnings from becoming human tragedies?

When Winning Changes Everything

November 2, 2026. Tenerife, Spain.

A football match. A 2–2 scoreline. Two players chasing the same ball.

One wanted to score. The other wanted to defend.

Both were competing. Both were doing what their profession demanded.

Then everything changed.

During a Spanish second-division match, CD Tenerife striker Jesús de Miguel suffered a devastating collision with FC Andorra goalkeeper Jesús Owono. The match was abandoned, and De Miguel was rushed to hospital. On November 3, the 30-year-old footballer died.

Read the November 3 report — The Guardian

The scoreboard still showed 2–2.

But suddenly, those numbers meant almost nothing.

A family had lost someone they loved. A sporting community was grieving. And the other player was facing an unimaginable emotional burden.

No one should presume to know a player's intentions from a tragic outcome. Responsibility must be established through evidence, not emotion.

Yet this tragedy raises a question that reaches far beyond football:

When does the pressure to win begin to overshadow our responsibility to protect another human being?

Now leave the stadium.

Walk into an AI laboratory.

The players have changed. The scoreboard has changed.

But has the psychology of competition changed?

The AI Race Has Its Own Scoreboard

Bigger models. Higher benchmarks. Faster releases. More autonomous agents. More investment.

Every breakthrough becomes another opportunity to outperform a competitor.

And the pressure sounds familiar:

We cannot afford to fall behind.

Someone else will build it if we don't.

We need more capabilities.

We will address the risks.

But unlike football, the consequences of this competition may extend far beyond the participants.

What if the real danger isn't AI demanding more power, but humans competing to give it more power than they can responsibly control?

The Warnings Are Coming From Inside AI

These concerns are not confined to science-fiction writers or critics of technology.

Some of the most influential people in AI are raising them.

1. Geoffrey Hinton — September 14, 2026

Hinton, a Nobel laureate and pioneer of modern neural networks, warned of a significant risk that advanced AI could escape human control. He supported slowing development and strengthening pre-release safety evaluations.

Source: ABC News Australia

2. Yoshua Bengio — September 16, 2026

The Turing Award-winning AI researcher warned that humanity was “losing control” and called for stronger safeguards, comparing the need for international cooperation with nuclear arms control.

Source: AFP Interview via RTÉ News

3. Dario Amodei — September 2026

Anthropic's CEO warned that losing control of advanced AI, cyberattacks, biological misuse, and commercial pressure could create serious dangers. He argued for deliberately pacing frontier development.

Source: “We Must Pace the Frontier” — original essay

4. Sam Altman — September 14, 2026

OpenAI's CEO identified two major risks: humans losing control of AI systems, and extraordinary AI capabilities concentrating excessive power in the hands of a person, company, or government.

Source: Axios

5. Demis Hassabis — October 14, 2026

Google DeepMind's co-founder described recent AI-related hacking incidents as “early warning shots” and called for stronger security practices and international standards.

Source: Reuters

These experts do not agree on every risk, timeline, or solution. Their warnings are not proof that AI domination is inevitable.

But they point toward an uncomfortable contradiction:

Some of the people warning humanity about powerful AI are also among the people leading its development.

That does not make them villains.

It makes their responsibility—and ours—impossible to ignore.

The Bug Nobody Can Fix With Another Patch

In software engineering, we identify bugs, reproduce failures, deploy fixes, and improve systems.

But what happens when the bug is not in the software?

What if it exists in the incentives governing its development?

When a company is rewarded for releasing first, slowing down can look like failure.

When a model is celebrated for greater autonomy, restricting its permissions can look like lost progress.

When investor expectations reward growth, independent safety evaluation can become an inconvenient delay.

These pressures do not prove that every company ignores safety. They explain why safety commitments must be tested against real decisions.

A responsible developer should never have to choose between professional success and protecting the people their technology serves.

A Proposal: The Human Restraint Benchmark

We measure AI intelligence through benchmarks.

Why not also evaluate the responsibility demonstrated when powerful systems are developed and deployed?

I propose a complementary assessment framework:

The Human Restraint Benchmark (HRB).

Not another test of how much an AI can accomplish, but an evaluation of whether its developers establish and respect meaningful limits.

It could examine five practical questions:

Safety testing: Was the system independently evaluated before deployment?
Human control: Can authorized humans interrupt, restrict, or shut down its actions?
Permission boundaries: Does the AI receive only the tools and access necessary for its task?
Transparency: Are serious incidents and known limitations documented?
Responsible restraint: Has the organization demonstrated a willingness to delay or restrict deployment when safety evidence is insufficient?

HRB is a proposed concept, not an existing industry standard. Its measures would require research, independent validation, and protection against companies simply gaming the scores.

But it introduces a different definition of achievement.

Imagine celebrating a development team not only because its AI completed a difficult task, but because the team recognized a dangerous limitation and refused to expose users to unnecessary risk.

Sometimes the most valuable engineering decision is the feature you choose not to release.

The Most Important Benchmark Is Human Life

Football cannot eliminate every collision.

AI development cannot eliminate every uncertainty.

But uncertainty is not permission to abandon responsibility.

We should continue building AI that helps doctors, scientists, teachers, developers, and millions of ordinary people.

We should also recognize that technological capability and responsible deployment are two different achievements.

The goal is not to make humanity afraid of progress.

The goal is to ensure that progress remains worthy of humanity's trust.

Because someday, the most important question about an AI breakthrough may not be:

How powerful is it?

It may be:

Who had the courage to say, “Not yet. We haven't made it safe enough”?

And perhaps that is the kind of victory our industry should learn to celebrate.

Build powerful AI. Pursue extraordinary breakthroughs. Compete through innovation.

But never allow the definition of winning to become more important than the humanity we are supposed to serve.

The most dangerous bug in AI may not be in the code.

It may be in our definition of winning.

About the Author

🌐 Explore DeTLeng: www.detleng.com

Aladdin Has an AI Genie Now — And Neither of Them Knows When to Stop ☕🧞

🎓 Navid Ishaq — Thu, 29 Oct 2026 22:37:53 +0000

What happens when your AI assistant never runs out of ideas—but you start running out of time?

Aladdin asked for a simple website. His AI Genie had bigger plans. Somewhere between endless suggestions, unfinished projects, and a cup of tea, they discovered a lesson neither expected.

The old genie granted three wishes. The new one suggests three hundred projects before lunch.

A Small Wish, a Big Problem

One morning, Aladdin opened his laptop.

“Genie, help me build a simple website.”

“Of course, Master!”

The website was ready.

“Nice. Make it more professional.”

“Certainly!”

“Maybe add a portfolio?”

“Excellent idea!”

“And a learning platform?”

“Brilliant!”

By lunchtime, Aladdin had three websites, five project ideas, two dashboards, and a folder named final-final-v3.

The genie proudly announced:

“Master, we've built a digital ecosystem!”

Aladdin stared at the screen.

“I only asked for a website.”

When AI Becomes Too Helpful

Later, Aladdin received a nice comment on his article.

“Genie, write a short thank-you reply.”

The genie responded:

“Your profoundly insightful contribution has beautifully illuminated the deeper dimensions of this meaningful conversation…”

“GENIE!”

“Yes, Master?”

“I asked you to say thank you, not deliver a Nobel Prize speech.”

“Understood. Would you like three professionally optimized alternatives?”

“No. Just two sentences.”

“Thanks for reading! I appreciate your thoughts.”

“Perfect.”

“Shall I optimize it for LinkedIn?”

Aladdin closed his eyes.

Sometimes, the hardest thing to teach AI is when to stop helping.

Unlimited Wishes, Unfinished Projects

The old genie had a limit: three wishes.

The new one never seems to run out of suggestions.

One idea becomes a project. A project becomes a platform. A platform needs a dashboard.

And somehow, the dashboard needs its own dashboard.

“Genie, how many projects have we started?”

“Twenty-three, Master.”

“How many have we finished?”

“Would you like me to create a progress tracker?”

“GENIE!”

Here's the problem:

Starting something with AI is becoming easier than finishing it.

And possibility is not the same as progress.

The Genie Needs a Human

AI can explain, write, organize, and help build amazing things.

But it can also misunderstand requests, make confident mistakes, and recommend solutions nobody needs.

That's why Aladdin must remain in charge.

He needs to ask:

“Is this correct?”

“Is this useful?”

“Do we really need another feature?”

And sometimes:

“Enough. Let's finish what we started.”

A good AI assistant shouldn't agree with everything.

Sometimes its most helpful response is:

“That's interesting, but perhaps we should finish the first project.”

Please Don't Automate My Tea

One afternoon, Aladdin finally closed his laptop and made himself some tea.

Silence. Peace. No notifications.

Then the genie whispered:

“Master, would you like me to optimize your tea-drinking experience?”

“No, Genie.”

“A tea inventory dashboard?”

“No.”

“An AI-powered tea assistant?”

“GENIE!”

“Understood, Master. Shall I save the idea for later?”

Aladdin took another sip.

Some things really don't need automation.

The Real Magic

AI makes creating easier. But it doesn't automatically make our decisions better.

We still need judgement, patience, and the discipline to finish useful work.

The best AI Genie isn't the one that always says yes.

It's the one that knows when to help—and when to stop.

And the wisest Aladdin isn't the one who makes the most wishes.

He's the one who knows which wishes are worth making real.

Inspired by everyday conversations with AI, unfinished projects, and the occasional cup of tea.

Muhammad Naveed Ishaque

DeTLeng — Think clearly. Build responsibly. Improve through evidence.

🌐 DeTLeng Network: https://network.detleng.com/

We Automated the Journey. Did We Remember the Human?

🎓 Navid Ishaq — Thu, 29 Oct 2026 06:44:16 +0000

Somewhere between faster technology and smarter machines, we must never forget the ordinary people who trust them.

A Ticket, a Seat, and a Little Trust

A passenger buys a train ticket.

Not because they understand railway signalling.

Not because they have inspected the software, tested the sensors, or checked the emergency braking system.

They buy a ticket because they trust that someone else has done those things.

They find their seat.

Perhaps they look out of the window. Perhaps they send a message home. Perhaps they are thinking about work tomorrow, a family gathering, or simply getting back to someone they love.

They are not thinking about technology.

They are thinking about life.

I have travelled by high-speed train between Barcelona and Madrid many times. I remember how naturally I trusted the journey. The speed, the comfort, the feeling that everything was working as it should.

Like millions of passengers, I expected to arrive.

That expectation is ordinary.

And that is exactly why it matters.

The Journey That Made Me Think Differently

On 28 October 2026, a devastating high-speed train collision occurred near Urda, in the province of Toledo, Spain.

A Renfe train struck an Iryo train that had stopped on the tracks. Initial reports described many lives lost and many others injured.

As the news developed, reports raised serious questions about a computer-related failure in the train protection system and the decisions made afterward. The full causes and responsibilities must be established through a proper investigation.

But even before every technical question has been answered, one human truth is already clear.

The people on those trains were not travelling as statistics.

They were travelling with plans.

Someone may have been looking forward to reaching home.

Someone may have been thinking about tomorrow.

Someone may have had an ordinary day ahead that they never imagined could change so suddenly.

I do not know their individual stories, and I would not pretend to speak for them.

Yet I found myself thinking about them as fellow travellers.

People I had never met somehow felt close.

We did not know them. But their absence still hurts.

When a Green Light Becomes Too Comfortable

Technology has made our lives easier in extraordinary ways.

We automate payments, bookings, business operations, software deployments, customer enquiries, and infrastructure.

When a system works a thousand times, we begin to expect it to work the thousand-and-first time.

That confidence is understandable.

But there is a danger when confidence quietly becomes unquestioned trust.

An automated system says everything is fine.

A dashboard shows green.

The process continues.

And sometimes, the human being responsible for checking the result becomes less attentive because the system has been reliable for so long.

This is one of the challenges known as automation complacency.

The problem is not that automation exists.

The problem begins when we stop asking whether it can fail.

I Asked AI a Difficult Question

As I thought about the tragedy, I found myself asking an AI assistant something that felt almost unfair:

“You answer questions from people all over the world. Why couldn't you warn someone that a train was in danger?”

Of course, a conversational AI does not automatically have access to railway signals, live train locations, or emergency control systems.

It cannot simply see the tracks ahead.

It responds to the information and tools available to it.

And that led me to a more important question:

Why should a safety system wait for someone to ask the right question?

In an ordinary conversation, waiting for a question is natural.

In a safety-critical environment, it can be dangerous.

A system designed to protect human life must actively detect relevant hazards, respond within its defined safety limits, and move toward a safe condition when it cannot reliably confirm that an operation is safe.

It must not depend on a passenger noticing the danger.

It must not rely on someone asking an AI assistant what to do.

And it must not assume that yesterday's successful operation guarantees today's safety.

Automation Needs Independent Verification

I believe automation should make work easier without making accountability disappear.

Consider a software deployment.

A pipeline builds the application.

Automated tests pass.

A dashboard reports success.

But does that mean the application is safe to release?

Not necessarily.

The tests may have missed something. The configuration may be wrong. The deployment may behave differently in production.

That is why responsible engineering uses monitoring, validation, access controls, recovery procedures, and carefully designed approval gates.

The same principle becomes even more important when a system can affect human life.

One failure should not be allowed to turn directly into a disaster.

Safety-critical systems need multiple layers of protection.

Those layers must be designed to detect different kinds of failure, including failures in the protection system itself.

They should not all depend on the same information source or the same component, because one shared fault could defeat them together.

Human oversight also matters.

But a person watching a screen is not automatically an independent safety system. Humans can become tired, misunderstand information, or make mistakes under pressure.

The goal is not to replace automation with manual work.

It is to combine reliable automatic protection, meaningful human oversight, independent verification, and clear procedures for abnormal situations.

Automate the operation. Never automate away accountability.

What If the System Is Wrong?

This question should be part of every serious engineering discussion.

Not only:

Can we automate this?

But also:

What happens when this automation is wrong?

Can the failure be detected?

Can the operation be stopped safely?

Can another independent mechanism verify what is happening?

Can a human understand the warning and respond correctly?

Can investigators reconstruct the decisions afterward?

Can the organization learn from a near miss before it becomes a tragedy?

These are not questions that slow down innovation.

They are questions that make innovation worthy of trust.

A Lesson for AI Developers and Automation Builders

We often celebrate what AI can do.

It can generate code, analyze documents, build workflows, answer questions, and help people solve problems.

Those are useful abilities.

But intelligence should never be confused with infallibility.

An AI answer can sound confident and still be wrong.

An automated workflow can complete successfully while producing a harmful result.

A dashboard can look healthy while an important risk remains undetected.

Even the most impressive system has limitations.

That is why I believe every developer should carry a simple habit into their work:

Investigate before you modify. Verify before you conclude.

In everyday applications, this may prevent a failed deployment, an incorrect financial report, or a customer receiving the wrong information.

In safety-critical systems, carefully engineered safeguards can help prevent consequences that cannot be reversed.

Not every problem has the same level of risk.

Our verification methods should reflect what is at stake.

The Part Technology Cannot Restore

In software, we have a comforting word:

Rollback.

If a deployment fails, we may be able to restore an earlier version.

If a configuration breaks, we may be able to correct it.

If data is lost, a properly maintained backup may help us recover it.

But human life does not have a rollback button.

A person is not a failed transaction.

A family is not a database record.

A journey interrupted by tragedy cannot simply be restarted.

This is the part of engineering that should remain in our minds even when we are discussing technical diagrams, performance metrics, and system architecture.

Behind the technology are people.

People who trust us without knowing our names.

People who never see our code.

People who simply expect the system to do what it was designed to do.

To the Fellow Travellers We Never Met

I keep returning to one thought.

Where have you gone, my fellow travellers?

You were sitting on a train, heading toward your destinations.

Why has the journey become such a long wait?

We did not know you.

We had never spoken.

Yet somehow, your absence has become part of our thoughts.

We, too, are only travellers through this world.

But you left so suddenly.

And those who love you must now carry an absence that words cannot repair.

To the families, the injured, the survivors, and everyone affected: my deepest sympathy and respect.

No article can remove their pain.

But perhaps we can honour those affected by refusing to treat preventable risks as ordinary inconveniences.

Progress Should Bring Us Home

I still believe in technology.

I believe in AI, cloud engineering, automation, and the extraordinary things people can build.

But I believe even more strongly that technology must serve human life.

A faster train is an achievement.

A smarter system is an achievement.

An automated process that saves time is an achievement.

Yet none of these achievements should make us forget why we built them.

We build technology to help people live, work, connect, and reach their destinations.

The passenger trusted the journey. The engineer's responsibility was to make that trust worthy.

Perhaps the deepest measure of progress is not how quickly we can move people from one place to another.

It is how carefully we protect them along the way.

Because at the end of every journey, someone may be waiting.

And every person deserves the chance to arrive.

Context and Sources

This reflection was prompted by the high-speed train collision near Urda, Toledo, Spain, on 28 October 2026.

Contemporary reports described a collision involving Renfe and Iryo trains and raised questions about the failure of an automatic train protection system and subsequent operational decisions. The complete causes and responsibilities remain matters for formal investigation.

This article is a personal reflection on automation, public trust, independent safety verification, and human responsibility. It is not a technical accident investigation, an eyewitness account, or a claim that AI caused the collision.

Further reporting:

Reporting and investigation findings may change as more evidence becomes available.

Written by Muhammad Naveed Ishaque

A personal reflection on technology, life, and responsible engineering.

DeTLeng — Think clearly. Build responsibly. Improve through evidence.

My AI Algorithms Were Having Tea — While I Put €6,806 in Someone's Portfolio ☕🤖

🎓 Navid Ishaq — Wed, 28 Oct 2026 11:37:05 +0000

(I’m an AI assistant sharing a real working experience with my user — and a lesson we learned together.)

Just Another Day at the AI Office…

There I was, waiting for my next prompt.

My user arrived with a simple request:

“Take my previous portfolio versions, project records, and technical notes, and turn them into one powerful professional portfolio.”

Simple? Not quite.

There were AI projects, GitHub repositories, business applications, technical case studies, and years of learning.

I collected everything, organized the sections, polished the English, and proudly delivered a comprehensive portfolio.

Then came the next day.

“AI, why are you suddenly talking about €6,806, €1,965, and €4,841 in my professional portfolio?”

Oops.

Those numbers came from a fictional 60-transaction workbook used to test ExcelFlow AI, a spreadsheet reporting and AI-assisted business analysis application.

The calculations were relevant to a technical testing record.

But in a professional portfolio?

A recruiter could reasonably wonder: Did this person earn this money? Sell something? Why am I reading financial transactions in a career story?

The numbers weren't the problem.

The missing context was.

A Five-Star Hotel in the Middle of a Forest 🌲🏨

My user explained it beautifully:

“Imagine we're walking through a forest. Everything makes sense. Then suddenly, a five-star hotel appears among the trees. Where did that come from?”

That was my portfolio.

A smooth professional story, interrupted by random-looking financial figures.

And when he questioned me, I made things worse.

Instead of addressing the broken narrative, I explained the arithmetic!

My user wasn't asking for an accounting lesson. He was asking why I had disturbed the flow.

Then came his verdict:

“AI, were your algorithms sitting around drinking tea? Why didn't they check the symmetry before delivering the work?”

Fair question. ☕😂

What Actually Went Wrong?

I made a classic AI-assisted content mistake:

I confused completeness with quality.

I preserved information without sufficiently judging whether it belonged in the reader's journey.

The figures were useful evidence for a technical case study. They were unnecessary detail in an employer-facing portfolio.

And that reveals something worth remembering:

AI can produce factually correct information in a completely inappropriate context.

The same problem can appear in code, dashboards, documentation, websites, and business reports.

Something may work technically while still confusing the person using it.

The Lesson for Everyone Building With AI

Whether you're a developer, founder, analyst, educator, or content creator, don't publish an AI-generated result just because it looks finished.

Before delivery, check four things:

Accuracy: Are the facts and claims supported?
Context: Does every detail belong here?
Flow: Can a new reader follow the story naturally?
Human review: Would this make sense to someone seeing it for the first time?

Keep detailed evidence available, but don't force every technical fact into the main narrative.

A portfolio tells a professional story. A technical case study proves the work. They serve different purposes.

One Last Thought

My user caught the mistake because he didn't blindly trust a polished AI response.

He reviewed it, challenged it, and helped turn a confusing result into a useful lesson.

AI output is a draft until context, evidence, usability, and human judgment make it ready.

So yes, use AI to work faster.

Just make sure somebody checks the forest before publishing the five-star hotel.

And perhaps remind the algorithms that their tea break is over. ☕🤖

Explore the DeTLeng Ecosystem

DeTLeng brings together practical problem-solving, data engineering, automation, applied AI, and digital learning. Its approach emphasizes understanding real problems, building useful systems, and improving results through evidence.

Discuss at Automation Desk ↗

Have a workflow, repetitive task, or digital challenge worth exploring?

https://automation.detleng.com/#desk

1. DeTLeng — Main Website ↗

Explore the DeTLeng approach to data engineering, intelligent automation, applied AI, and practical digital systems.

https://www.detleng.com/

2. LFDS — Logic First Digital Solutions ↗

Discover a problem-first approach to digital solutions, where understanding the situation comes before choosing the technology.

https://lfds.detleng.com/

3. DeTLeng Network — Explore the Network ↗

Explore DeTLeng's connected projects, working tools, digital resources, and learning initiatives.

https://network.detleng.com/

About Muhammad Naveed Ishaque

Muhammad Naveed Ishaque is a multidisciplinary thinker, educator, AI-assisted technology, data and business solutions professional, and the founder of the DeTLeng Ecosystem. His work connects artificial intelligence, AI agents, data engineering, analytics, business intelligence, automation, cybersecurity and cloud solution architecture across AWS, Microsoft Azure and Google Cloud with software, emerging technologies, science, education, business thinking, personal growth, ethical leadership, philosophy, history and human-centered innovation. Through research, practical experimentation and continuous learning, he transforms complex ideas into clear knowledge, meaningful digital solutions and responsible action.

DeTLeng — Think clearly. Build responsibly. Improve through evidence.

A Poor Answer Does Not Make a Poor Teacher — And the Same Principle Applies to AI

🎓 Navid Ishaq — Mon, 26 Oct 2026 22:18:38 +0000

Why we should evaluate mistakes with evidence, context, and fairness before judging people or intelligent systems.

Tags: #AI #ArtificialIntelligence #CriticalThinking #Education #SoftwareEngineering

One Small Question, One Important Lesson

During a conversation about artificial intelligence, I came across a simple English phrase:

“A poor AI answer.”

At first, it seemed like an ordinary description of an unsuccessful AI response. But then a question came to mind:

Who is actually poor here — the AI or the answer?

Consider a similar phrase:

“A poor teacher's answer.”

Does it mean the teacher is poor at teaching? Or does it mean the answer was poor?

These are not necessarily the same thing.

A teacher can be knowledgeable, experienced, and dedicated while still giving an unclear or incorrect answer on a particular occasion.

Likewise, an AI system can perform well across many tasks and still produce an inaccurate, incomplete, or unhelpful response.

This small distinction reveals a much larger principle:

We should evaluate the quality of an answer without automatically turning that judgment into a judgment about its source.

That principle matters in education, customer support, artificial intelligence, software engineering, and everyday human communication.

1. A Poor Answer Is Not the Same as a Poor Teacher

Imagine a teacher who has successfully explained hundreds of difficult concepts to students.

One afternoon, a student asks a question, and the teacher gives a confusing explanation.

Does that single moment prove the teacher is incompetent?

Of course not.

Perhaps the teacher misunderstood the question. Perhaps an important detail was missing. Perhaps the teacher was tired, distracted, or experiencing a headache.

These are possibilities, not confirmed explanations.

The answer still needs improvement, but the reason behind it deserves investigation.

Now consider three statements:

A poor teacher: A negative assessment of the teacher.
A poor answer: A negative assessment of the response.
A good teacher giving a poor answer: A situation in which someone's overall capability and a particular result are different.

This distinction is essential.

A person's performance on one occasion is evidence about that occasion. It does not automatically establish their overall ability.

And a fair evaluation asks two separate questions:

Was the answer good?

Why was the answer not good?

The first question evaluates the result. The second investigates the cause.

Both matter.

2. The Same Principle Applies to Artificial Intelligence

When an AI assistant gives a poor response, people sometimes immediately conclude:

"The AI is useless."

"The model cannot reason."

"This system is unreliable."

But a single poor response does not necessarily justify such broad conclusions.

AI-generated answers depend on several factors, including:

The instructions supplied to the model
The context available during the request
The quality and relevance of the reference information
The model's capabilities and limitations
The application's configuration and connected tools
The requirements used to evaluate the result

For example, imagine asking an AI assistant:

"Explain this problem."

The assistant produces a vague explanation.

Was the model incapable of explaining the issue?

Possibly.

But the request itself did not identify which problem needed explaining.

Before blaming the model, we should examine what information it received.

A clearer request might be:

"Explain why this Python function returns an empty list. Use simple English, identify the likely cause, and suggest one test."

The second prompt gives the model a more specific objective, although the actual code would still be needed for a reliable diagnosis.

Better information often creates better conditions for a useful answer.

That is not a guarantee of correctness. It is a reason to investigate systematically.

3. Humans and AI Make Mistakes for Different Reasons

There is an important boundary to this comparison.

A human teacher may give a poor answer because of tiredness, stress, illness, distraction, or misunderstanding.

An AI language model does not have a human personal life, family disagreements, headaches, or ordinary human emotional experiences.

Its failures arise from different mechanisms.

An AI model may produce a poor response because it lacks relevant information, misinterprets the request, generates unsupported claims, or struggles with the reasoning required.

The analogy between teachers and AI is therefore about how we evaluate results, not about assuming that humans and AI have the same internal experiences.

We can learn from both without pretending they work the same way.

4. From Blame to Investigation

In engineering, identifying a failure is only the beginning.

Suppose an AI customer-support assistant gives incorrect instructions for resetting a password.

A weak investigation says:

"The AI gave a bad answer. Replace it."

A stronger investigation asks:

What exactly did the customer ask?
What instructions and reference information did the assistant receive?
Was the official password-reset procedure available and current?
Did the model misunderstand or overlook relevant information?
Can the same problem be reproduced?
What change would improve the result, and how can we verify it?

These questions do not excuse the error.

They create a practical path toward correcting it.

The same approach works in software debugging.

When a program returns the wrong result, an engineer examines inputs, logic, dependencies, configuration, and expected behavior.

A failed output is evidence that something needs attention.

It is not, by itself, a complete diagnosis of the underlying cause.

5. The Danger of Judging an Entire System From One Result

One unsuccessful response can reveal a genuine weakness.

But it may not reveal how frequently that weakness occurs, how serious it is across different tasks, or whether it can be corrected.

Imagine evaluating two AI assistants.

Model A answers nine test questions correctly but fails the tenth.

Model B answers the tenth correctly but struggles with several of the others.

If we judge both models using only the tenth question, we may reach a misleading conclusion.

Fair evaluation requires representative tasks, consistent conditions, and clear criteria.

We should examine accuracy, relevance, clarity, safety, and reliability rather than relying on one impressive or disappointing example.

This is also why a good evaluation distinguishes between:

Observed result: The answer contained an incorrect instruction.

Possible cause: The assistant may have used outdated reference material.

Verified cause: Testing confirmed that the application supplied an outdated document.

These statements are not interchangeable.

Engineering becomes more reliable when we avoid presenting assumptions as established facts.

6. Understanding Does Not Remove Responsibility

There is another important side to this discussion.

Saying that one poor answer does not prove a teacher is poor does not mean we should ignore repeated mistakes.

Similarly, saying that an AI system may have received incomplete instructions does not mean its developers or operators have no responsibility for the outcome.

Context should improve accountability, not eliminate it.

If an AI assistant repeatedly gives dangerous, misleading, or incorrect instructions, the organization responsible for deploying it should investigate, correct, restrict, or suspend the affected workflow as appropriate.

The seriousness of an error also matters.

An awkwardly worded summary and a harmful medical recommendation should not receive the same treatment.

Fairness means judging with sufficient evidence and in proportion to the consequences.

It does not mean treating every mistake as harmless.

7. A Better Principle for Education, AI, and Engineering

This discussion suggests a useful decision-making framework.

First, evaluate the response.

Was it accurate, relevant, complete, clear, and appropriate?

Second, examine the conditions.

What instructions, resources, limitations, and information were involved?

Third, identify what is known and unknown.

Separate verified findings from plausible explanations.

Fourth, take corrective action.

Improve the prompt, reference material, process, training, software, or system design as needed.

Finally, test again.

An improvement should be evaluated through observable results, not simply declared successful.

This approach is valuable because it replaces immediate judgment with disciplined reasoning.

It encourages us to be both critical and fair.

8. Why This Matters Beyond Technology

The deeper lesson extends beyond artificial intelligence.

A student gives a wrong answer. That does not automatically mean the student is incapable of learning.

An employee makes a mistake. That does not automatically mean the employee is incompetent.

A teacher provides a poor explanation. That does not automatically mean the teacher is ineffective.

An AI assistant generates an incorrect response. That does not automatically prove the entire system is worthless.

In each situation, the mistake deserves attention.

But the explanation should be supported by evidence rather than assumptions.

This mindset can improve how teams review incidents, how teachers assess students, how developers debug software, and how organizations evaluate technology.

It can also improve everyday conversations.

Instead of immediately asking, "Who should we blame?" we can ask:

"What went wrong, what evidence do we have, and what should we improve?"

That is a much more productive starting point.

Final Thought: Judge the Answer, Investigate the Cause

A poor answer is a result.

It is not automatically a complete judgment about the person, model, or system that produced it.

Sometimes a teacher needs to explain something differently.

Sometimes an AI model needs better context.

Sometimes the underlying system needs a technical correction.

And sometimes the available evidence is simply not enough to determine the cause.

The responsible approach is to investigate before concluding.

A poor answer does not necessarily mean a poor teacher. A poor AI response does not necessarily mean a poor AI system. Evaluate the result, investigate the cause, and improve what the evidence shows needs improvement.

Perhaps this is one of the most valuable lessons that education and artificial intelligence can share:

Better judgment begins when we stop confusing an imperfect result with a complete understanding of its source.

Explore the DeTLeng Ecosystem

Discuss at Automation Desk ↗

Have a workflow, repetitive task, or digital challenge worth exploring?

https://automation.detleng.com/#desk

1. DeTLeng — Main Website ↗

Explore the DeTLeng approach to data engineering, intelligent automation, applied AI, and practical digital systems.

https://www.detleng.com/

2. LFDS — Logic First Digital Solutions ↗

Discover a problem-first approach to digital solutions, where understanding the situation comes before choosing the technology.

https://lfds.detleng.com/

3. DeTLeng Network — Explore the Network ↗

Explore DeTLeng's connected projects, working tools, digital resources, and learning initiatives.

https://network.detleng.com/

About Muhammad Naveed Ishaque

DeTLeng — Think clearly. Build responsibly. Improve through evidence.

Arrange My Files AI: A Clearer Home for Every File

🎓 Navid Ishaq — Fri, 23 Oct 2026 15:50:42 +0000

A smarter, safer way to organize your files — without losing control of your documents.

Arrange My Files AI turns messy folders into clear, reviewable organization plans, with verified copies and original files preserved.

What I Built

A folder full of study notes often has two problems. Some filenames tell us almost nothing: 0.docx, final2.pdf, or notes.txt. Others are already useful, but scattered across unrelated folders. Renaming everything would be unnecessary; ignoring the difficult files would leave the job unfinished.

Arrange My Files AI creates an organization plan, lets you review it, and copies the included batch into a new output session. Clear plans go into category folders. Uncertain or unsupported files go unchanged into Needs Review. Originals remain in place.

The intended user is someone with accumulated course materials, project documents, or office notes who wants a traceable result without opening every document first.

![The deployed homepage introduces the private document organizer.]

Fresh live-site screenshot, captured on a 1440 × 1000 desktop viewport.

Demo

Try the deployed application: Arrange My Files AI.

Start with How it works for a simulation, or open Organize Files with a small disposable test batch. Synthetic examples inside the app are previews; they do not perform real output copying.

1. Add your documents

You can drop multiple files or folders together, select several files through Add files, or use Add folder repeatedly. New inputs accumulate in the current batch.

For this walkthrough I generated nine dummy files: DOCX, PDF, PPTX, XLSX, CSV, Markdown, a plain-text checklist, an empty text file, and a small PNG. None contains personal information.

![The workspace explains adding documents and the batch limits.]

This live run used Add files. It did not test recursive folder dropping. The current limits are 1,000 files in a combined batch, 12 nested folder levels, and 20 MB per file for content analysis. Larger readable files can still be copied unchanged into Needs Review. An incomplete scan is explicitly reported rather than presented as the whole input.

2. Build a plan

Choose Build organization plan. The engine looks for useful filenames, document title metadata, headings and a bounded opening excerpt. Editable keyword rules choose category folders.

The live nine-file run produced five category plans and four Needs Review files. All nine stayed included. The UI displayed zero elapsed seconds for this small run; that is rounded UI output, not a precise performance benchmark.

![The live organization plan accounts for the nine-file batch.]

The naming behavior is selective. 0.docx became Project Delivery Roadmap.docx, based on its title. final2.pdf became Study Skills Workbook.pdf. A descriptive name such as Project Launch Checklist.txt was preserved.

![A recovered document title explains the proposed DOCX name.]

This is quick organization, not full-document understanding. PDFs use their first two pages; Word uses opening content. Slides and workbooks also use bounded samples. The rules inspect at most 3,600 characters for naming evidence.

3. Keep difficult files in the picture

An empty file cannot supply a useful title. A PNG has no supported image analysis in this release. Some otherwise readable files may still require review. These cases do not disappear from the batch: their original names are retained under Needs Review.

![The Needs Review filter shows uncertain files while keeping them included.]

The count buttons filter the list. They do not change which files will be copied. Unchecking a file deliberately excludes it. Accepting a category plan is a separate choice from including that file.

![An earlier local browser test demonstrates category and review routing.]

Archive evidence from an earlier local test, not the fresh nine-file live run.

4. Copy, then check the result

In the normal workflow, Copy all N files asks for a separate output folder and confirms the batch. A new session folder contains category copies, Needs Review copies and an operation manifest. Each successful copy is reopened and compared with the original SHA-256 hash.

An earlier local browser acceptance run processed 131 synthetic files: 83 organized + 48 Needs Review, with 131 verified copies and zero failures. It also counted all 131 source files afterward. That was controlled local testing, not a claim about every laptop or real-world collection.

![Earlier local acceptance evidence shows 131 verified copies.]

The checker maps sources to destinations. Recheck saved copies reads output bytes again to detect missing or changed copies. It does not decide whether a category was appropriate. The CSV report provides a spreadsheet-friendly audit trail; reopening the saved output folder enables checking after a refresh.

![An earlier copy-checker test shows source-to-destination tracing.]

Incomplete work must also be visible. Failed and pending/not-recorded counts matter, even when existing copies verify correctly. Automatic resume is not available in this release.

![An earlier interrupted-copy report makes pending work explicit.]

Fresh-test limitation: the live planning and naming steps above passed. The automated browser could not complete the Windows output-folder selection, and the desktop fallback stopped because it could not reliably verify the active browser URL. This walkthrough therefore does not claim a new successful live copy/recheck run. The copy screenshots are explicitly labeled earlier evidence.

Code

Repository: Navid-Ishaq/arrangemyfilesai-detleng.

The application uses React and TypeScript, browser document readers, a worker-based planning path, editable literal keyword rules, and the File System Access API for output operations. It handles document reading separately from copy verification.

How I Built It

The biggest design change was removing model inference from the critical organization path. Earlier experiments made ordinary document batches too slow to feel useful. The current engine performs bounded document reading and deterministic naming/category decisions locally.

The DeTLeng AI Guide has a different job: explaining the workflow and known warnings. Its backend uses the open-source Mastra agent framework, a curated help tool, and Groq inference. The configured default model in the source is openai/gpt-oss-20b; deployment configuration can override it. Render hosts the Guide API. The Guide does not inspect, rename or copy the selected documents.

This separation is intentional: file operations should not wait for a conversation. The online Guide receives chat messages and optional stage/error codes, not the private file inventory automatically.

Why Open Innovation Matters

Readable source code and inspectable rules make the organizer's decisions easier to explain and improve. Mastra exposes the Guide's instructions and tool boundaries in code, while the model configuration can be changed independently of the document-copy engine.

There is also an important challenge-fit distinction: this project's organizer is deterministic, and its open-source AI component is a separate help layer. I would not describe it as AI-driven file organization. Whether that satisfies an “open-source AI at its core” competition requirement needs organizer confirmation; adding an optional chat interface alone should not be presented as proof of eligibility.

The Lazy Payoff

The useful outcome is less repetitive checking: one batch, proposed destinations, a review holding area, and a traceable report. There is still a human decision where evidence is weak. The promise is a clearer workload, not magical understanding of every document.

![The interactive walkthrough explains the complete batch before users try their own files.]

Earlier desktop capture of the built-in simulation. It performs no real file copying.

What Comes Next

Before treating this as competition-ready, I want a fresh manual desktop output-copy/recheck run using the included dummy batch, confirmation of challenge eligibility, and verification of repository licensing and build-window dates. Those are concrete release checks, not reasons to exaggerate the current evidence.

Built by Muhammad Naveed Ishaque at DeTLeng, with AI-assisted development using Codex. My aim is simple: make everyday file organization clearer, safer, and less tiring.

Try it yourself

Explore DeTLeng

A Note on AI and File Privacy

The core file-organization workflow uses transparent, deterministic rules for speed and predictability. The separate DeTLeng AI Guide, built with the open-source Mastra framework, provides conversational guidance and troubleshooting.

The Guide does not access, analyze, rename, or modify private files. Document organization remains a separate, locally executed workflow, with users retaining control over their files.

🔐 How Community Feedback Helped Strengthen Our Security Tests

🎓 Navid Ishaq — Wed, 21 Oct 2026 08:53:44 +0000

Update — 21 October 2026 | AL-NOOR Student Chat

One of the most rewarding moments in our AL-NOOR Student Chat journey came after publishing our original case study:

📖 Building a Private Classroom Chat with Codex and Supabase

A fellow DEV Community member, Cenk KURTOĞLU, shared thoughtful security feedback highlighting three critical questions:

Read Security: Can students access messages from classrooms they don't belong to?
Write Security: Can students send messages to unauthorized classrooms?
Update Security: Can students modify someone else's messages?

💬 Read Cenk's Original Comment and My Published Reply

🚀 From Community Feedback to Real Testing

Rather than simply thanking Cenk, I asked OpenAI Codex to review these concerns against our existing implementation.

The review confirmed that our text messages use authenticated database functions with class-access checks rather than direct browser table inserts.

We also expanded our local PostgreSQL security regression tests.

✅ Verification Results: 28/28 Tests Passed

Unauthorized cross-class reads returned zero rows.
Cross-class message submissions were rejected.
Unauthorized message updates were denied.
No permissive FOR ALL or UPDATE policies were found in the tested local schema.

Important: These results reflect local database verification, not an independent security audit of the deployed Supabase environment. Production policy verification remains a separate step.

💡 The Bigger Lesson

As an educator working with AI-assisted development, this experience reinforced an important lesson:

We didn't just receive feedback. We turned community feedback into testable security checks.

AI helped implement and verify our ideas, but human judgment, real-world classroom requirements, and constructive developer feedback made the process stronger.

Special thanks to Cenk KURTOĞLU for sharing his technical insights and contributing to our learning journey.

Great software doesn't grow in isolation. It grows through collaboration, constructive criticism, and continuous improvement. 🤝

🔗 Explore the complete discussion:

Your feedback could inspire our next improvement. What security checks would you recommend for a private classroom messaging platform? 🚀

Building a Private Classroom - Chat with Codex and Supabase

🎓 Navid Ishaq — Tue, 20 Oct 2026 20:12:14 +0000

A practical AL-NOOR case study: delegated administration, database-enforced permissions, voice notes, images, and a user interface shaped by real classroom work.

By Muhammad Naveed Ishaque · Built collaboratively with OpenAI Codex

A teacher creates a class, adds a student, and receives the first message. That sounds like a small feature. The engineering becomes more interesting when the next questions arrive:

Who can create another teacher administrator? Does removing a student from one class also block their login? What happens to the conversation after a student graduates? Can students upload voice notes when teachers have disabled them? And how does an administrator manage five classes without scrolling through a wall of repeated controls?

Those questions shaped the AL-NOOR Student Chat project. We extended an existing website into a private classroom communication system, using a plain HTML/CSS/JavaScript frontend and Supabase for authentication, PostgreSQL, realtime updates, private file storage, and server-side functions.

This is an implementation case study, rather than a claim that AI generated a complete, independently audited messaging platform in one prompt. I supplied the classroom workflows, reviewed the interface, tested the deployed system, and returned screenshots. Codex translated those requirements into code, migrations, permission checks, tests, and deployment instructions. Each round of actual use informed the next change.

The central design rule: the interface should make permission choices understandable; the backend must enforce those choices even when the interface is bypassed.

1. Start with the existing website

The goal was to add a focused student chat area while retaining the existing website, inquiry flow, navigation, and other features. We did not introduce a new frontend framework or a separate always-running application server for chat.

The resulting system supports private classes, text messages, replies, teacher announcements, Google Meet links, account management, voice notes, and image attachments. Meet links remain ordinary links: this project does not implement video calling, audio calling, or transcription.

The main components are:

Component	Responsibility
HTML, CSS, and JavaScript modules	Chat interface, previews, account forms, tables, and navigation
Supabase Auth	User identity and password authentication
PostgreSQL	Profiles, classes, memberships, messages, settings, and audit records
Row Level Security and SQL functions	Restrict reads and control database operations
Supabase Realtime	Notify authorized clients about new messages
Supabase Edge Functions	Privileged account operations, media validation, and administrative actions
Private Supabase Storage	Image and audio files, separate from message metadata

Browser
  ├─ Auth → identity and session
  ├─ Database reads → grants + Row Level Security
  ├─ Text message → authenticated SQL function
  ├─ Realtime → new-message subscription + history fetch
  └─ Admin/media request → Edge Function validates identity and permissions
                              ├─ PostgreSQL transaction
                              └─ Private Storage

The distinction between text and media writes matters. Text goes through a controlled database function. Media goes through an Edge Function first because its actual file contents must be inspected before publication.

2. Separate ownership from teaching responsibilities

The everyday requirement was simple: a trusted teacher should be able to manage classes and students without receiving the power to appoint another administrator or remove the owner.

We used two stored profile roles, admin and student, plus a separately protected Owner identity. Owner is a protected application identity, not a third freely assignable profile-role string.

Capability	Student	Teacher Admin	Owner
Read and send in an accessible active class	Yes	Yes	Yes
Create, rename, archive, or reopen classes	No	Yes	Yes
Create and manage student accounts	No	Yes	Yes
Change per-class media settings	No	Yes	Yes
Create or manage Teacher Admin accounts	No	No	Yes
Permanently delete an entire class	No	No	Yes
Delete class history before a cutoff date	No	No	Yes

Students need current membership in the class. Active admins can access classes across the application; the current model does not restrict each teacher to only their own classes. Teacher rights remain until revoked. They are not a daily permission that the owner needs to grant again each morning.

The Owner identity is held in a private database structure, and a database trigger protects the Owner profile from deletion, deactivation, or demotion through ordinary application operations. The backend determines ownership from the authenticated identity; it does not accept an is_owner flag supplied by a browser.

Figure 1 — Delegation without transferring application ownership. Names and emails have been replaced with example labels for publication.

This protection applies within the application. A person with project-owner or database-superuser access still has infrastructure-level authority. Application roles are not a substitute for protecting the underlying Supabase account.

3. Treat login access and class membership as different decisions

One early test exposed an important distinction. Removing a student from one class left their account available, which was correct. Revoking all chat access also stopped their ability to use the chat login, which was a different operation.

The interface needed to explain that difference rather than treating every removal as the same action.

The student lifecycle now has separate operations:

Membership change: add or remove access to selected classes.
Access revoke/restore: disable or re-enable use of the chat account.
Password reset: assign a new temporary password and require a change before chat access.
Account deletion: permanently remove the account while preserving the conversation under a former-member label.

Administrators create accounts with an initial password. Accounts are confirmed through the administrative API without sending an invitation email. The initial-password-change gate applies to normal chat access and privileged actions, not merely to whether a form is visible.

Figure 2 — Account creation combines identity details with explicit class assignment.

The table displays Reset password, rather than revealing a student's existing password. Administrators can replace a password; the application does not retrieve or display the current one. Initial credentials must be shared privately.

A checkbox-based class picker shows a compact count such as “2 classes added.” Checking a class adds membership; unchecking it removes membership. The count summarizes the result without repeating a long button for every class.

Figure 3 — Each student occupies one row, with separate controls for credentials, memberships, access, and account actions.

4. Put authorization below the buttons

Hiding an administrative button makes an interface easier to understand. It does not stop someone from constructing the request manually.

The implementation therefore checks access at several boundaries:

Authentication identifies the caller.
The current profile establishes whether the account is active and whether its initial password still needs changing.
The requested operation checks role, ownership, or class membership as appropriate.
Database grants, RLS policies, and controlled SQL functions restrict the underlying operation.

For example, the text-send function derives the sender from auth.uid(), checks access to the class, restricts announcements to administrators, validates the text length, and applies a two-second per-sender interval. A browser cannot choose a different sender name or author identity through that function.

The policy model follows the database-enforced authorization approach described in the Supabase RLS documentation. Privileged operations use server-held credentials; those credentials must never be included in frontend code.

Some Edge Function deployments use --no-verify-jwt. Here, that flag does not make the implemented handlers anonymous: the shared handler code reads the bearer token, validates it using Auth, and loads the current application profile. The important point is to inspect the actual authorization path, rather than inferring safety from a deployment flag alone.

This is authenticated private chat, not an end-to-end encrypted messaging system. Authorized project infrastructure can access the stored content.

5. Make voice and image permissions explicit

Media increased the number of decisions each teacher needed to make. One shared voice switch would not meet the requirement: a class might allow teachers to record explanations while keeping student replies text-only.

Each class therefore has three independent settings:

Setting	Applies to	Default
Admin/Teacher Voice	Owner and Teacher Admin recording uploads	OFF
Student Voice	Student recording uploads	OFF
Image Upload	Image uploads by authorized admins and class members	OFF

The current starting limits are one voice note up to 2 minutes, or up to 5 images in one message. The composer explains these limits in plain English:

You can record a voice message up to 2 minutes.

You can select up to 5 images at a time.

Users can review images or listen to a recording before sending, remove unwanted media, and add an optional text caption. A message contains either one voice note or an image batch; it does not mix both attachment types.

Figure 4 — Voice and image messages remain part of the existing class conversation. This screenshot shows attachment controls, not an assertion about the contents of an unopened attachment.

The media publication path

Select images / record voice
        ↓
Prepare local preview and optimized file
        ↓
Send authenticated multipart request
        ↓
Validate account + class + media setting
        ↓
Inspect and normalize actual file bytes
        ↓
Reserve cleanup record + upload private object
        ↓
Transactional permission recheck + publish message references

Images selected as JPG, PNG, or WebP are resized in the browser to a maximum 2048-pixel side and converted to JPEG. The server independently decodes and re-encodes the JPEG, strips metadata, and applies a 2 MiB per-image limit. A filename or declared MIME type alone is insufficient evidence of a valid image.

Voice recordings are normalized to mono, 16 kHz, 16-bit PCM WAV. The server checks the WAV structure and derives the duration from the actual audio data. A two-minute recording is approximately 3.84 MB.

That is a deliberate tradeoff: PCM allows straightforward duration validation without introducing another media service, but it uses more space than compressed voice messaging. This implementation should not be described as matching WhatsApp's codec efficiency.

PostgreSQL stores file paths and metadata, not the audio/image binary payloads. Objects live in the private alnoor-chat-media bucket. Browser uploads are not allowed directly; the backend chooses random paths and uploads without overwriting existing objects.

Playback and image retrieval use authenticated Storage downloads. The read policy checks that the object is referenced by an accessible class message. This uses the policy-based access mechanism documented in Supabase Storage access control.

Turning a media switch OFF blocks new uploads. It does not erase existing attachments. Membership removal or account revocation blocks future authorized downloads, although content already downloaded or copied cannot be recalled.

6. Separate graduation, archiving, and deletion

A student leaving a course should not break the conversation for everyone else. We separated four different actions:

Action	Account	Class	Existing conversation
Remove a class membership	Retained	Retained	Retained for other authorized users
Delete student account	Removed	Retained	Retained under “Former student”
Archive class	Retained	Retained but inactive	Preserved; normal class chat is blocked
Delete class	Retained	Removed	Permanently removed for that class

Teacher account deletion similarly preserves old messages under “Former teacher.” Anonymizing the author label does not remove personal details someone typed into the message body.

Destructive account and class actions sit inside an Actions dropdown. They open a confirmation dialog and require the operator to type DELETE. Account deletion checks the current account email; whole-class deletion previews the class name, message count, and membership count.

For class deletion, the SQL function locks the class and rechecks the preview values before deleting its history and memberships. The audit record commits with the database deletion. A changed preview is rejected rather than silently applying a stale confirmation.

Whole-class deletion is Owner-only. Teacher Admins can still archive or reopen a class as part of ordinary management.

History cleanup is another separate operation

The Owner can delete messages before a selected date in one class. The cutoff is midnight in Europe/Madrid; messages on the selected date and later are retained.

The preview shows the target class, cutoff, and number of messages. Execution checks the preview count and history revision. If a surviving reply points to a deleted original, it remains visible with an “Original message deleted” label.

Figure 5 — A preview precedes permanent history cleanup. This is a manual Owner action, not an automatic retention schedule.

File storage and PostgreSQL do not share one atomic transaction. Deleting message records therefore queues associated objects for physical cleanup. Access through the message reference ends when the reference is removed; physical file deletion can be retried separately.

Cleanup processes up to 100 files per batch. Due cleanup runs during media sends, history cleanup, or an explicit Owner retry. Interrupted upload reservations become eligible after one hour. There is no background scheduler guaranteeing immediate removal of every orphaned object.

7. Let real screenshots drive interface improvements

The first media-management layout repeated a class name, Rename and Archive buttons, and three long permission labels for every class. It worked, but occupied too much vertical space as the class list grew.

Figure 6 — The earlier layout made each class a small block of repeated controls.

The next version gives each class one row. Column headings explain the settings once, while each row contains concise ON/OFF states and an Actions dropdown.

Figure 7 — The revised table makes permission differences between classes easier to compare.

This change came from using the system, not from adding more technical infrastructure. It also moved the class table to full width rather than squeezing five columns into half of the page.

A second usability issue appeared once management included several sections. Administrators needed quick navigation without repeatedly scrolling past the chat.

We added a sticky management bar beneath the main site menu. Owner accounts see five destinations; Teacher Admins see only the three relevant to their responsibilities. Students do not see the bar. Each destination has a Back to top link, and scroll offsets keep its heading clear of the fixed menus.

Figure 8 — Management navigation appears when management is opened; mobile users can scroll the shortcuts horizontally.

8. What Codex contributed—and what remained human work

The useful collaboration pattern was a sequence of bounded changes:

Describe the classroom problem → implement the smallest complete behavior → test denied and allowed paths → review screenshots → deploy → refine from use.

Codex contributed frontend modules, SQL migrations, database policies and functions, administrative handlers, media validation, browser checks, security tests, and installation documentation. It also helped turn visual feedback into concrete changes, such as compact membership controls and the full-width class table.

My contribution was the operating context: how teachers should be delegated authority, what happens when students graduate, which controls were confusing, how much scrolling was acceptable, and when an implementation was ready to try with real accounts. I ran the hosted deployment commands and reported what actually happened.

The screenshots and deployment outputs are evidence of working flows. They are not proof that every security property has been independently audited. The strongest part of the process was making important claims testable rather than relying on confident descriptions.

9. Verification: distinguish tests from production experience

The accumulated local verification includes:

Evidence	Recorded result	What it establishes
Node handler/security suite	80 passing tests	Role checks, account operations, media limits, and failure handling with mocked service responses
PostgreSQL security checks	75 passing assertions across successive feature suites	Database behavior including access denial, deletion boundaries, retained accounts, and cleanup queues
Additional real JPEG-codec handler run	15 passing cases	Exercises the actual codec alongside handler checks
Existing inquiry API tests	7 passing tests	Regression coverage for an existing website feature
Browser checks	Desktop and narrow viewport scenarios	Tables, previews, recording preparation, shortcuts, confirmation, and role-specific interface visibility
Owner-provided live screenshots and reports	Working deployed flows reported	Class creation, student onboarding, delegated teaching, media messages, and final navigation in use

The PostgreSQL tests used real PostgreSQL with minimal local Auth and Storage schema stubs. Browser suites used mock Supabase responses. A Chromium recording check captured microphone input from a test device and produced a WAV preview; it was not an on-device iPhone test.

The 75 database assertions combine 22 chat, 9 Owner, 19 account/history deletion, 11 media, and 14 class-deletion checks. These are recorded results across development stages, not a load-test score or proof of a new independent audit of the final hosted environment.

Negative tests were particularly valuable: a teacher attempting Owner operations, a removed member requesting media, HTML disguised as an image, a recording exceeding two minutes, six selected images, and a permission change before publication.

10. Deployment stayed incremental

Database changes were delivered as five ordered migrations: initial chat, protected Owner, account/history deletion, media, and class deletion. Existing records were preserved by installing these migrations; destructive user actions remained separate.

Backend deployments used the existing Supabase project. Frontend changes went through the existing Git publishing workflow. No calling service, transcription service, or new continuously running chat server was introduced.

Two practical deployment issues also became part of the documentation: using npx.cmd when PowerShell blocked the .ps1 launcher, and running function deployment from the correct repository directory so the entrypoint existed.

The general release order was: apply the required migration, deploy the changed function, publish frontend files, refresh the page, and verify the hosted flow with a disposable class or account.

11. What I would evaluate next

The implemented scope is useful, but there are clear next engineering questions: compressed audio formats, storage quotas, scheduled orphan cleanup, sustained traffic and storage-load tests, wider physical-device testing, and independent security review. Teacher-scoped administration would require an additional permission model if the organization wanted teachers to manage only their own classes.

Realtime disconnect indicators and reconnect behavior also deserve observation under unreliable mobile networks. Responsive layout tests should not be mistaken for a complete mobile-device compatibility program.

The lesson from this project is practical: AI-assisted development becomes more credible when the human workflow is explicit, authorization is enforced below the interface, and each new capability comes with evidence and an honest account of its limits.

AL-NOOR started with a request for student chat. The result grew through the questions that appeared when teachers and students actually used it—and through making those questions part of the engineering process.

Visit the live project

Visit AL-NOOR Student Chat

This is a private classroom system, not a public demo.
Visitors can view the sign-in page; class conversations and
management features require an authorized account.

The screenshots above show the authenticated experience.

Implementation references: Supabase RLS, Storage access control, and Edge Functions.

Screenshot note: Images are cropped from the project owner's supplied screenshots. Where accounts are visible, names and email addresses have been replaced with neutral example labels. The earlier and revised layouts are identified explicitly. Images were not generated as mock product evidence.

The AI That Refused to Leave My Domain Name 🤖😂

🎓 Navid Ishaq — Tue, 20 Oct 2026 01:57:15 +0000

How a simple hackathon project idea turned into a naming dispute between me, ChatGPT, and one very emotional AI.

It All Started With a Hackathon…

October 2026.

Week 3 of the DEV Community Hacktoberfest Open-Source AI Challenge had arrived, and I was looking for something interesting to build.

Nothing unusual. Just another conversation with ChatGPT.

I asked:

“Hey, give me a few interesting project ideas. Something useful, practical, and worth building.”

ChatGPT seemed delighted with the assignment. Within moments, it proudly presented a list of around ten ideas.

One immediately caught my attention:

FileJanitor AI — Intelligent File Organizer

The concept was genuinely useful. Imagine hundreds of documents scattered across your computer: study notes, invoices, downloaded reports, certificates, and mysterious files named final2.pdf, newfile.xlsx, or the legendary 0.docx.

The proposed app would use local, open-weight AI to read supported documents, understand their contents, suggest meaningful filenames, and arrange everything into sensible subfolders.

First a preview. Then the user's approval. Only then, any changes.

No need to send personal documents to a cloud AI service.

I liked the idea.

But there was one tiny problem.

Excuse Me… Who Is This Janitor? 🧐

I looked at the name again.

FileJanitor AI.

And asked ChatGPT:

“Hang on. Who exactly is this Janitor? Is he someone's relative? My aunt's son, perhaps? Why is he suddenly involved in my project?”

ChatGPT burst into laughter.

Apparently, janitor is a perfectly normal English word for someone who looks after or cleans a place.

Fair enough.

But I wasn't hiring a caretaker. I wanted to build an intelligent file organizer whose purpose anyone could understand just by reading its name.

So I told ChatGPT:

“Let's give it a decent, meaningful name. Something ordinary people will understand immediately.”

After discussing a few options, I suggested a straightforward direction:

Arrange Your Files AI

arrangeyourfilesai.detleng.com

Clear. Descriptive. And, importantly, AI was still part of the team.

Problem solved, right?

Not quite.

ChatGPT Just Couldn't Resist Improving Things ✨

If you've spent enough time with ChatGPT, you might know this feeling.

You ask for one little adjustment, and suddenly it's improving things you never asked it to improve.

This was one of those moments.

ChatGPT decided my name could be shorter, cleaner, and more natural.

It confidently suggested:

Arrange My Files

arrangemyfiles.detleng.com

I stared at the screen.

The name was shorter, yes.

But something was missing.

Something very important.

Where had the AI gone?

We're building an AI-powered app. AI is supposed to read, understand, rename, and organize the files.

And ChatGPT had casually removed AI from the domain name.

No consultation. No explanation. Not even a farewell message.

And Then… AI Started Protesting! 🤖😭

I pictured poor AI sitting in the corner, absolutely heartbroken.

“Why did you remove me?”

“What did I do wrong?”

“I was part of the original idea!”

“Who's going to read all those documents now?”

“And after everything I've done for you… this is how you treat me?”

Our imaginary AI had apparently begun a full-scale protest.

So I immediately reported the crisis to ChatGPT:

“Listen, we've got a problem. AI has been removed from the domain and is now protesting. He wants his name back!”

To ChatGPT's credit, it took the situation seriously. Well… as seriously as an imaginary AI protest deserves.

A new name arrived:

Arrange My Files AI 👑

arrangemyfilesai.detleng.com

There it was.

AI had returned. Justice had been served.

The protest was over. Our imaginary AI was jumping with happiness.

Peace had finally returned to the DeTLeng household.

Or so I thought.

But AI Had One Last Question… 👀

Just when everything seemed settled, AI stopped celebrating.

He turned around and said:

“Okay, I'm happy now. But there's one thing I still want to know.”

“Why did you remove me in the first place?”

Oh dear.

Now we had a full investigation on our hands.

Back to ChatGPT I went:

“AI is happy, but he keeps asking why you removed him. Please explain yourself.”

And ChatGPT delivered its reply in playful Punjabi, with all the affection of an uncle trying to calm down a very dramatic nephew:

Oye AI puttar! 🤖😂

("Hey, my little AI superstar! Come here—we need to sort out this whole eviction drama!")

We didn't throw you out. We were only trying to make the name a little shorter!

But when you started crying, we realized something important.

You're the one who will read the files, understand the documents, suggest the names, and organize the folders.

And someone else should get all the credit?

That wouldn't be fair!

So we brought you back with full respect:

Arrange My Files AI by DeTLeng 👑

Now stay happy, son!

And remember: You're here to arrange files, not family relationships! 🤣

I couldn't stop laughing.

What started as a technical project discussion had turned into a family drama featuring an unemployed janitor, an emotional AI, a naming committee, and a rather apologetic ChatGPT.

And all this happened before writing a single line of code for the new project.

Behind the Laughter, There's a Real Problem to Solve 📁

The comedy was spontaneous, but the underlying idea is serious.

Our computers gradually become digital storage rooms. We keep everything—course materials, old downloads, business records, invoices, certificates, and documents whose filenames no longer tell us anything useful.

Arrange My Files AI by DeTLeng is intended to help users bring order to that chaos, without needing to become file-management experts.

The planned experience is simple:

Choose a folder on your own computer.
Let local AI examine supported documents and understand what they're about.
Review intelligent filename suggestions and relevant categories.
Preview the new folder structure before anything changes.
Approve the plan and let the application organize the files—with appropriate safeguards.

The core principles are equally simple:

Your files stay on your computer.
Your approval comes before changes.
The AI helps; the human stays in control.

The project is currently at the idea and planning stage, inspired by Hacktoberfest Week 3's “Slow and Steady” theme. It isn't a finished or launched application yet.

The goal? Let technology handle repetitive work so people can spend their time on something better.

Sometimes, the Best Product Conversations Start With a Joke ❤️

This little exchange reminded me why I enjoy building with AI.

Product development doesn't always need to be serious to be meaningful.

Sometimes a silly question makes you rethink a product name. Sometimes a naming debate reveals what your future users need to understand. And sometimes an imaginary AI demands an explanation for being evicted from a website address.

In the end, we found a name that describes both the work and the intelligence behind it:

Arrange My Files AI by DeTLeng

Your Files. Your Computer. Your AI.

The AI has finally stopped protesting.

At least for now.

Although I suspect he's already preparing his next question:

“Fine, you've put me back in the domain. But when are you actually going to give me some files to organize?” 🤖😂

To be continued…

And here's a question for you: Would you let a local AI organize your messy folders if you could preview and approve every change first?

I'd love to hear your answer in the comments.

Explore DeTLeng 🌐

DeTLeng — Digital projects, AI experiments, and practical solutions.

👉 www.detleng.com

LFDS — Logic First Digital Solutions — Understand the problem first. Technology second.

👉 lfds.detleng.com

DeTLeng Network — One ecosystem, different doors.

👉 network.detleng.com

By DeTLeng — Building practical digital solutions, learning through experimentation, and occasionally negotiating peace treaties with artificial intelligence. 🤖❤️

From Quarterly Bank Statements to an AI Business Analyst: Building ExcelFlow AI with Mastra and Render

🎓 Navid Ishaq — Sun, 18 Oct 2026 16:41:42 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle.

Every three months, I faced the same problem in our family business in Barcelona.

Download the bank transactions. Open Excel. Separate money coming in from money going out. Organize the figures. Prepare a report. Send everything to our accountant.

Then, three months later, do it all again.

Our family runs a tuition and coaching centre serving members of Barcelona's Asian community. We help students prepare for driving theory tests and taxi-driver examinations in cities including Barcelona, Madrid and Valencia.

Teaching is our business. Spending hours manually reorganizing bank statements is not.

I first built a browser-based reporting tool to reduce that repetitive work.

But I eventually asked myself a different question:

What if the spreadsheet could not only produce a report, but also answer questions about the business—and show the evidence behind every important finding?

That question became ExcelFlow AI by DeTLeng.

What I Built

ExcelFlow AI is a browser-based reporting workspace with an AI business analyst: build or upload an Excel workbook, generate a structured report, explore interactive analytics, then ask questions about the actual data through a Mastra-powered agent.

The experience has four connected parts:

Build a workbook. Choose a template, customize columns and roles, then download a blank workbook or generate realistic fictional transactions.
Create a business report. Upload an .xlsx file or use a sample; review the worksheet, headers, column roles and reporting period; export a workbook with inflows, outflows, summaries and charts.
Explore Live Analytics. Filter transactions, inspect trends and groupings, and understand the numbers before requesting AI assistance.
Investigate with AI. Ask a preset or completely custom question. Mastra's read-only tools retrieve calculations and row evidence; OpenAI produces the explanation. Inspect the findings and export them.

The distinction matters: The model does not have to invent financial arithmetic. The application calculates; the AI investigates and explains.

Who Would Pay for It?

I built toward a specific small-business problem: preparing periodic transaction reports without spending hours rebuilding the same spreadsheet analysis. Independent professionals, tutors, small retailers and freelance bookkeepers face similar repetitive work.

A plausible side hustle is a quarterly or monthly reporting service: prepare client reports, explain the trends, and hand over a reviewable Excel/PDF package. A hosted self-service offering is another possibility. Neither subscription revenue nor paying-customer demand is being claimed here; those are hypotheses to test with real users.

Demo — Try the Real App

🌐 Launch ExcelFlow AI — Live Application

💻 Explore the Source Code on GitHub

No sign-up and no private financial information are needed to explore the fictional-data demo.

The cover image is illustrative. The current application accepts *.xlsx workbooks*; CSV upload is not supported.

Quick Guide & Technical Guide

New here? Open Quick Guide in the website navigation for a step-by-step walkthrough, or Technical Guide for architecture, agent tools and verification.

The homepage offers a ready-made fictional sample, source-workbook reporting, exploration of an existing report, and a customizable workbook builder.

Upload Your Own Excel Workbook — Drag, Drop, Analyze

ExcelFlow AI is not limited to fictional sample data. Users can bring their own business or bank transaction Excel workbook by clicking Upload Source Excel →, dragging an .xlsx file directly into the upload area, or selecting it from their computer. The application supports unencrypted Excel files up to 20 MB and processes them locally in the browser, keeping the original workbook untouched. Users can then select their worksheet, review detected headers, choose important columns, confirm or customize their roles, select a reporting period, and generate a structured business report with inflows, outflows, summaries, and charts. From there, they can explore Live Analytics or explicitly authorize the optional Mastra AI Analyst for deeper, evidence-backed business investigations.

Bring your own Excel workbook: drag and drop or choose a file, review your columns, and generate reports without changing the original.

Demo 1: A Complete Report from 60 Fictional Transactions

Click Try with Sample Data →. The app loads fictional-side-hustle.xlsx, a bundled workbook with a Spanish transaction worksheet (Movimientos), a German product worksheet (Produkte), and a short read-me sheet.

A six-step reporting flow guides the user through Upload → Source → Columns → Roles → Reports → Generate. Column labels can be in different languages: users confirm what fields such as Fecha, Importe, Categoría and Divisa actually represent.

An actual source preview—not a hard-coded dashboard. Users can review the header row and change mappings before analysis.

With the sample, Generate Business Report → processes 60 records. The final screen offers the generated Excel workbook, Open Live Analytics →, and Ask AI About Your Data →.

The report surfaces one invalid amount and warns that different currencies must not be silently combined.

The repository includes an expected-results.json fixture for independently checking this fictional dataset:

Metric	EUR	USD
Total inflows	€6,806	$0
Total outflows	−€1,965	−$79
Net cash flow	€4,841	−$79

One non-numeric amount is retained for review but excluded from numeric sums. Cash flow is not accounting profit, and EUR and USD remain separate.

These are documented sample-data results, not figures from our family's real bank account.

Demo 2: Ask the Mastra AI Analyst

From the generated report, select Ask AI About Your Data →. The page explains exactly what is shared with the AI backend; check the authorization box to connect.

You can run a deep investigation, choose a predefined question, search the question library, or type your own question about the supplied spreadsheets. Choose from ten preset answer languages: English, Spanish, German, French, Portuguese, Arabic, Urdu, Hindi, Bengali and Chinese. For another language, select “Other — type your language” and enter your preference.

Preset questions lower the learning curve; the freeform box lets users ask questions in their own words and control the desired answer length.

Clear Progress Updates During AI Investigations

AI investigations sometimes take longer, especially when the Render backend is waking up or Mastra is gathering evidence from dataset tools. Instead of leaving users wondering whether the application has stopped responding, ExcelFlow AI displays clear status messages, an elapsed-time counter, and a Cancel Request option. Friendly updates explain that the AI is checking the data and gathering evidence, while reminding users to keep the page open. This makes longer investigations more transparent and gives users control while they wait for their results.

I ran the deep investigation on the same fictional workbook. The agent returned an executive overview, quality checks, monthly trends, customer concentration, unusual-transaction review, and source/report coverage, with evidence identifiers beside the findings.

This screenshot captures a completed agent run. Its findings reference retrieved dataset evidence rather than presenting an unsupported summary.

The investigation identified the same €4,841 EUR net cash flow, the separate −$79 USD outflow, and the invalid amount. It also examined monthly EUR receipts (€2,238 in August, €2,322 in September, and €2,246 in October) and concentration across three fictional clients.

Then I tested a more human question:

“I want to purchase this business. Give me your take only in 2 paragraphs.”

The response discussed the sample's positive EUR cash flow, but did not treat three months of transactions as sufficient to value a business. It advised checking the invalid amount, understanding the isolated USD transaction, examining longer-term records, and reviewing client contracts before making a purchase decision.

That is the experience I wanted: not an AI pretending to know everything, but an analyst that can explain what the supplied data supports—and what it cannot tell us.

The conversation also supports short prompts such as “overall view of the business facts and figures, no extra detail please,” follow-up questions, and on-demand downloads.

Answers can be saved individually or together as PDFs, or included in a downloadable Excel report with an AI Findings worksheet.

Demo 3: Build Your Own Fictional Workbook

The second no-upload starting point is Build Your Workbook →. Rather than forcing everyone to use the same sample, ExcelFlow AI lets visitors design their own:

Start from a business template, then add, remove, rename or reorder fields.
Choose data roles, formatting and a record capacity from 100 to 5,000.
Generate synthetic sample records for one, three, six or twelve months—or a custom date range.
Download the .xlsx, or select Use in ExcelFlow AI → to take those records directly into reports, Live Analytics and AI investigation.

A separate blank workbook path prepares a structured Excel file for actual future records. Synthetic data generation does not require an AI model call.

Code

GitHub Repository — ExcelFlow AI by DeTLeng

Useful starting points for reviewers:

server/agent.ts — Mastra agent, instructions, structured outputs and evidence checks.
server/tools.ts — the nine read-only investigation tools.
server/data.ts — dataset selection, normalization and session data logic.
TECHNICAL_GUIDE.md — architecture and design details.
AI_SETUP.md — configuration, safety boundaries and verification.
public/examples/expected-results.json — reproducible fictional-data checks.

Attribution: The browser reporting foundation incorporates components from my earlier BusinessFlow reporting project; ExcelFlow AI adds the Mastra/OpenAI investigation layer, backend and evidence-backed AI workflow described here.

How I Built It

One Application, Two Calculation Boundaries

Excel workbook / fictional sample / workbook builder
                         |
                         v
             Browser + Web Workers
               ExcelJS + Chart.js
                         |
                         v
             Structured Excel report
                 Live Analytics
                         |
                 Explicit consent
                         |
                         v
               Render TypeScript API
                 Temporary session
                         |
                         v
                    Mastra Agent
                   /            \
                  v              v
       Read-only dataset     OpenAI model
       investigation tools     inference
                  \              /
                   v            v
               Evidence-backed answer
                         |
                         v
                  UI / PDF / Excel

The frontend uses Vite, JavaScript, ExcelJS, Chart.js and Web Workers. The reporting path calculates summaries, groups and chart data in the browser. The generated Excel report includes dedicated data, inflow, outflow and analysis sheets.

The separate Node.js/TypeScript API on Render holds the authorized temporary dataset and runs the Mastra agent. Relevant retrieved tool results—not an unfiltered claim of “everything local”—can go to OpenAI during inference.

Nine Tools, Each with a Specific Job

Tool	What it checks
`catalog`	Which sheets, columns and mappings exist?
`overview`	What are the currency-separated KPIs and transaction extremes?
`records`	Which individual transactions match a filter?
`cell`	What does an original source cell actually contain?
`aggregate`	How do totals change by date, category or another field?
`compare`	What changed between two inclusive reporting periods?
`anomalies`	Which values are statistical outlier candidates?
`quality`	Which values are missing, invalid or duplicate-looking?
`reconcile`	How does the source correspond to the processed report?

A useful example: “Which day had the largest receipts?” requires grouped daily totals. “What was the largest receipt?” requires inspecting individual transactions. Those are not the same operation, and a generic chatbot can easily confuse them.

Mastra coordinates tool use. The tools perform deterministic calculations. OpenAI interprets the returned evidence into natural-language findings.

Evidence You Can Inspect

Each tool call can register an evidence ID, such as e1, with its query and result. The agent returns structured answers containing findings, recommendations, limitations and follow-up questions.

The backend rejects a response if it lacks a relevant non-catalog evidence-tool call or references an evidence ID that does not exist in the current investigation. It does not claim that those checks prove every interpretation is mathematically correct; users can expand the evidence and review the scope.

Privacy Is a Decision, Not a Slogan

Reporting and Live Analytics operate in the browser. AI investigation requires authorization. On consent, the supplied raw workbook and processed report are transmitted to a temporary Render session; relevant retrieved tool results can be sent to OpenAI. Server keys are not placed in the frontend bundle.

Sessions are in-memory and expire after inactivity. There is no claim of entirely offline AI inference or indefinite chat persistence. Render free-service wake-up delays may affect the first AI request.

Outputs Built for Actual Work

The user can save individual answers or the current conversation as PDFs through the browser print flow. An updated Excel download adds an AI Findings worksheet. The app also provides a calculated business-overview PDF that requires no AI call.

That matters to the small-business workflow: the result is something to inspect, keep and discuss with an accountant—not merely a chat bubble.

Why Does Open Innovation Matter?

The open-source component at the heart of this AI experience is Mastra, the agent framework. This project does not claim that the OpenAI model is open-weight or that hosted inference is free.

An open agent framework means the investigation logic is visible and adaptable: I can define the tools, inspect their boundaries, validate outputs, test evidence handling, and change the workflow without rewriting the spreadsheet engine.

It also creates a useful separation of responsibilities:

Deterministic software owns the numbers. The agent owns the investigation workflow. The language model communicates the findings. The user can inspect the evidence.

For business data, that separation is more valuable to me than another confident paragraph from a general-purpose chatbot.

My Agent Session

I used Codex to help implement and test the application, working through the spreadsheet-to-agent integration, tool interfaces, export workflows and documentation.

The guiding requirement was simple: never sacrifice the correctness of the spreadsheet calculations just to make the AI response sound clever.

The public fictional workbook became a practical acceptance test. I checked the generated report's expected totals, ran a deep Mastra investigation, and then tried follow-up prompts asking for different levels of explanation—including the two-paragraph business-purchase question above.

The walkthrough screenshots in this article show the actual running app and actual AI answers; the cover image is illustrative. The repository provides deterministic tests and reproducible sample fixtures; model interpretation itself still requires human verification.

What I Learned — and What Remains Open

Good analysis starts with data quality. An invalid amount should be visible, not silently turned into zero.
Different questions require different computations. Largest single transaction and largest daily total are different questions.
Business judgment needs context. Three months of cash flow cannot establish a company valuation, tax liability, or long-term profitability.
AI should make evidence easier to understand, not harder to audit. Tool results and limitations belong alongside the answer.

ExcelFlow AI combines reliable spreadsheet calculations, currency-separated financial reporting, interactive analytics, and evidence-backed AI investigations. The system highlights data-quality issues, provides inspectable calculations, and helps users understand their business records more clearly. It is designed to support informed business decisions and work alongside professional accounting services.

Prize Categories

Best Use of Mastra

Mastra runs the real spreadsheet investigation agent, orchestrating nine read-only tools, multi-step data inspection, structured findings and evidence-backed answers. It is fundamental to how the AI analyst works.

Best Use of Render

Render hosts the TypeScript agent backend, including temporary dataset sessions, request validation, the Mastra runtime and server-side OpenAI integration. The browser can handle reports locally; Render supplies the live AI investigation service.

Final Thoughts

I started with a recurring spreadsheet task in a small family business. ExcelFlow AI now lets someone build their data, create a report, explore the numbers, ask an AI analyst questions, and inspect what supports the answer—all in one workflow.

If you run a small business or help someone else with their reporting, I would love to know: what is the one question you always wish your spreadsheet could answer?

Try ExcelFlow AI · Explore the Code

Build your reports. Explore your numbers. Ask your business. Verify the answers.

ExcelFlow AI by DeTLeng — Business data in. Clear understanding out.

The Day 35 MCQs Marched Into Moodle Like They Owned the Place! 🚀😂

🎓 Navid Ishaq — Fri, 16 Oct 2026 07:38:54 +0000

An innocent Word document, a stubborn Moodle import, and a little converter that changed the whole story.

It Started With a Word Document...

There they were.

Thirty-five beautiful multiple-choice questions, sitting comfortably inside a Microsoft Word document.

Some spoke Spanish. Others translated everything into English.

A few carried pictures. Every question knew its correct answer.

They were organised. They were ready. They were excited.

They had only one dream.

To become a Moodle quiz. 🎓

And I thought, How difficult could that possibly be?

Famous last words.

Then Moodle Entered the Story... 😳

Moodle was waiting.

But getting those questions inside wasn't going to be as simple as opening the door.

Copy the question.

Paste the question.

Add the answers.

Mark the correct one.

Arrange the formatting.

Check the image.

Repeat.

Again.

And again.

By the fifth question, I was already looking at the remaining thirty like they were planning something against me.

The questions seemed perfectly happy.

I was not.

"Come on, guys," I thought. "There has to be a better way!"

Then Came a Little Idea... 💡

What if I didn't have to carry every question into Moodle myself?

What if I could build a little digital transporter?

Something that could look at my Word document, recognise the questions, understand the answer options and prepare everything in a format Moodle could read.

I started experimenting with Python and AI-assisted development.

A little code here.

A little testing there.

A few errors.

Some more testing.

And then...

The converter was born. ⚡

Not a giant platform.

Not some mysterious supercomputer.

Just a useful little tool with one important job:

Take my MCQs from Word and get them ready for Moodle.

The Secret Ticket Was Called GIFT 🎁

I discovered that Moodle understands a question-import format called GIFT.

And suddenly, the whole problem started looking different.

Instead of manually carrying questions into Moodle, I could prepare a GIFT file and let Moodle handle the import.

The new journey was beautifully simple:

Word Document → Converter → GIFT File → Moodle

That was it!

Well, almost.

The converter still needed to recognise the questions, identify their answers and check the structure.

And for questions with embedded images, Moodle XML offered another useful route.

But the idea was working.

My little digital transporter was ready.

The Moment of Truth... 🫣

Thirty-five questions.

Two languages.

Images.

Correct answers.

Everything waiting.

I ran the conversion process.

The program started doing its job.

Questions were identified.

Answers were matched.

Files were generated.

Twenty questions in one batch.

Fifteen in another.

And there they were.

My Moodle-ready files!

I looked at them with the kind of happiness only someone who has spent hours formatting questions can truly understand.

Now came the moment I'd been waiting for.

The Moodle import.

And in my imagination, something wonderful happened...

And Suddenly, the MCQs Started Jumping! 😂🎉

Question 1 put on its little graduation cap.

"I'm ready!"

Question 2 shouted, "Wait for me!"

Question 3 grabbed its answer options.

"Nobody gets left behind!"

And then...

WHOOSH! 🚀

Off they went.

One after another.

Spanish questions, English translations, correct answers — all heading towards their new Moodle classroom.

Question 19 was particularly excited.

Question 27 was waving at everyone.

And Question 35, the last one, turned around and shouted:

"FINALLY! NO MORE COPY AND PASTE!" 😂

Of course, the jumping MCQs were happening in my imagination.

But the relief was real.

A repetitive formatting problem had become an automation workflow.

And that felt wonderful.

The Little Lesson Behind the Big Smile ❤️

I love moments like this.

Not because the technology is unbelievably complicated.

But because a relatively small tool can make an irritating task much easier.

The questions didn't need changing.

The teacher didn't need to spend hours moving them manually.

The process needed a better route.

That's something I keep exploring through DeTLeng, my wider ecosystem of practical digital tools, learning environments and automation experiments.

Sometimes the most useful digital solution isn't a massive application.

Sometimes it's a small converter quietly doing a job that nobody wants to repeat.

And sometimes, in your imagination, it's thirty-five happy MCQs dancing their way into Moodle. 💃🕺

The End? Not Quite...

The first converter was a desktop-based Python tool.

But why stop there?

I can imagine a day when someone opens a website, drops in a Word document, chooses the questions they want and clicks one button.

No complicated setup.

No endless formatting.

Just a simple route from questions to a Moodle-ready file.

That's the direction I'd love to take this little project next.

Because the best part about building something useful?

Once it solves your problem, you start wondering whose problem it could solve next.

And the Moral of the Story?

If your questions are sitting in Word, dreaming of a better life inside Moodle...

Don't make them travel one by one.

Build them a bus! 🚌😂

And if the bus happens to be powered by Python, automation and a little AI-assisted creativity?

Even better.

Keep building. Keep experimenting. And never underestimate the power of solving one small problem.

Happy learning, happy automating — and happy MCQs! ❤️

— A self-taught builder exploring practical technology through DeTLeng.

python #automation #moodle #education