Evidence Gate

Evidence Gate stops AI from giving hardware instructions when the facts are unclear. It only allows action when there is enough evidence and a person has confirmed it.

Comment

Inspiration

This project started from a real problem in my own Terelia Garden smart-irrigation project.

Over time, I had collected different notes, screenshots, instructions, measurements, and conversations. Some of them were made for an older ESP32-C3 prototype, while the current system was already using a KinCony T16M controller.

The old instruction still looked believable, but it no longer belonged to the current hardware. If I had followed it without checking, I could have connected the new controller incorrectly.

That gave me the idea for Evidence Gate.

I wanted AI to help find conflicts and explain what was wrong, but I did not want AI to decide by itself that something was physically correct or safe.

What it does

Evidence Gate checks whether there is enough evidence to approve one specific instruction.

In this demo, the question is:

Can we approve today’s Valve 1 wiring instruction?

GPT-5.6 reads the available project sources and notices that the old ESP32-C3 instruction and the current KinCony T16M information belong to different controller setups.

It explains the conflict and shows what proof is still missing.

The application then uses fixed rules.

If the sources do not match, the instruction stays blocked.

Information found by AI is treated only as a possible claim. It does not become verified evidence automatically.

To continue, a person must confirm the real measurement, including:

  • which controller was measured;
  • which terminals were used;
  • whether the output was on or off;
  • the measured value;
  • the unit;
  • the time;
  • who checked it;
  • and that the information is correct.

In the demo, the real commanded-on measurement is 11.89 V DC from OUT1 to COM.

After the measurement is confirmed, the application allows only the instruction for this exact T16M case.

The old ESP32-C3 note is not deleted. It stays visible, but it no longer controls this specific decision.

Every important change is recorded in the audit history.

If new important evidence arrives later, the system can reopen the case and ask for another review.

“Safe to proceed” does not mean that the whole electrical system is certified as safe.

It only means that this one instruction has enough evidence for this tested controller, terminal, operating state, and decision.

How we built it

I started with the product idea and the real hardware problem.

Codex helped me turn that idea into a working application.

It helped build:

  • the evidence structure;
  • the rule-based decision gate;
  • the user interface;
  • the human confirmation process;
  • the GPT-5.6 connection;
  • the evidence validator;
  • the audit trail;
  • the tests;
  • the production build;
  • and the project documentation.

GPT-5.6 does the language and analysis work.

It reads the sources, extracts possible claims, keeps the original source references, compares the controller contexts, finds the conflict, and explains what evidence is still needed.

But GPT-5.6 cannot mark something as verified or safe.

Only the application rules and a confirmed human observation can change the decision state.

The application uses Node.js, JavaScript, HTML, and CSS.

The OpenAI API key stays on the server. The AI response must follow a fixed structure before the application accepts it for further checking.

Challenges

The hardest part was deciding where AI should help and where it must stop.

AI is useful for reading different documents and finding contradictions, but it cannot physically see the controller, hold the multimeter probes, or confirm that a real measurement was performed correctly.

Another challenge was keeping the old evidence visible instead of simply deleting it.

The system had to show that the old instruction was real, but also explain why it could not automatically be reused for the current controller.

We also had to make sure that:

  • incomplete evidence cannot pass;
  • evidence from the wrong controller cannot pass;
  • an AI answer cannot approve itself;
  • resetting the demo returns it to the correct starting state;
  • new evidence can reopen a finished case;
  • and the final result stays limited to one clear decision.

Accomplishments

I am proud that the project became a real, working public application.

It includes:

  • a live GPT-5.6 analysis;
  • real KinCony T16M evidence;
  • authentic physical measurements;
  • human confirmation;
  • source references;
  • deterministic blocking rules;
  • a scoped final instruction;
  • an audit trail;
  • a working public deployment;
  • a passing evidence validator;
  • a passing production build;
  • and 21 out of 21 deterministic tests passed.

The full demo can be tested in about two minutes.

What we learned

The biggest lesson was that AI does not need to make the final decision to be useful.

GPT-5.6 is very helpful for reading, comparing, explaining, and finding missing information.

But the final state change should still depend on clear software rules and human responsibility.

For me, trust does not mean pretending that everything is certain.

It means keeping the original sources, showing what is verified and what is not, recording who confirmed the evidence, and explaining why the decision changed.

What’s next

Right now, Evidence Gate demonstrates one focused hardware case.

The next step would be to use the same idea for more situations, such as:

  • hardware development;
  • maintenance work;
  • manufacturing changes;
  • laboratory procedures;
  • technical instructions;
  • and other projects where an old or unsupported instruction should be blocked until there is enough current evidence.

The goal is to help teams avoid real-world mistakes caused by outdated, mixed, or unverified project information.

Built With

Share this project:

Updates