My experience building an evidence-backed business workflow, connecting an AI agent to Mattermost, and learning why verification matters more than confident AI answers
**
It started with a simple question**
Imagine ordering a pair of headphones online, The website promises delivery tomorrow. It says the headphones are available, and you have thirty days to return them.
Sounds perfectly reasonable
But what if the company actually needs two days to deliver? What if those headphones are out of stock?
Now imagine something slightly different
What if those promises were correct when the company approved them, but became incorrect the following day?
Should an announcement remain published simply because somebody approved it yesterday?
That question became the starting point for Proofline - Evidence Before Promises my project for the Flip the Switch Hackathon 2026
I didn't want to build another AI chatbot that generates marketing content, I wanted to explore something more useful, an AI-assisted workflow where statements are checked against business records, publication requires human authorization, and changing facts can automatically invalidate an earlier approval
What I built
Proofline is a local Node.js application for reviewing business announcements, A marketing team submits a draft. An AI agent can investigate the claims and prepare structured corrections, But the backend -not the language model-decides whether the facts support those claims!
The application, doesn't ask an AI model whether the announcement sounds believable, Its backend checks structured claims against current operational records using explicit rules.That matters because a convincing explanation isn't evidence
The workflow
I divided responsibilities between the agent, the business application, and the human reviewer.
- Investigate The agent reads the marketing request and checks the current business data.
- Verify Proofline evaluates the structured claims independently. Unsupported promises are blocked.
- Correct The agent can propose corrections, such as changing Berlin delivery to two days and removing the unsupported stock claim.
- Approve The corrected proposal is checked again, an evidence receipt is prepared, and a human manager decides whether to publish it.
- Revalidate Even after approval, the public announcement remains dependent on current evidence. That last step became my favorite part of the project :)
Even after approval, the public announcement remains dependent on current evidence.
The feature I cared about most
Let's say the manager approves the corrected announcement -
"Delivery to Berlin within two business days." The statement is accurate, Now The announcement goes live, Now imagine that the delivery estimate changes to four business days because of an operational delay. Proofline, checks the previously approved statement against the new value The claim is no longer supported, so the public page changes to WITHHELD The earlier approval remains in the audit history, but customers no longer see the outdated promise, Hence, Yesterday's approval cannot make today's false promise true
For me, that's the distinction between generating content and building accountable business software
*Where Switch comes in *
I created an agent called proofline-agent and joined it to the proofline-review room, Instead of giving Codex unrestricted access to the application, I built a command-line interface around specific operations.
For example :-
node _.\tool.mjs facts
node .\tool.mjs inbox
node .\tool.mjs case PL-1000_
The agent can use these commands to inspect business records and prepare case updates, The manager's publication decision remains separate, This approach lets the AI help with the work without making it responsible for the final truthfulness or authorization decision.
The part that didn't go according to plan
A few moments where things got interesting, while building this amazing tool!
I was building this on Windows, using Switch Console, Docker Desktop, Mattermost, and Codex signed in through my ChatGPT account,The Proofline backend worked, and all six automated tests passed. However, connecting everything was considerably harder than I expected
Problem 1:- The agent was looking in the wrong directory,
My first real agent message was quite simple -
Read AGENTS.md and run node tool.mjs facts.
Codex attempted the commands, Result, Both failed, The application was in my project folder, but Switch had started the agent under a separate directory inside .switch/agents. The agent was effectively looking for files in a folder where they didn't exist, What really, helped was using an absolute path to the application tool instead of assuming the current working directory was the repository.
For example -
node "C:\path\to\Proofline-BuiltByBhavesh\tool.mjs" facts
My takeaway- Verify the agent's working directory before giving it a multi-step task. An agent may understand the assignment and still fail because its execution environment is different from yours!
#Problem 2
During setup, Windows Security reported that codex-windows-sandbox-setup.exe had been blocked from modifying my protected Documents folder, The protection was Controlled Folder Access
That was another layer of confusion, because Codex itself had installed successfully, I didn't establish that this security warning was the root cause of the later agent failures, and I wouldn't recommend disabling Windows Security or excluding an entire agent directory just to make a demo run.
A safer approach is to inspect the specific blocked application, verify its installation source, keep project work outside protected system folders where appropriate, and only grant narrowly scoped permissions when necessary.
My takeaway- Security controls should be investigated, not blindly bypassed!
#Problem 3 My Codex authentication token was revoked
This one interrupted the later stages of development, Codex started reporting an authentication failure -
401 Unauthorized token_revoked
The message indicated that its saved refresh token could no longer be used, I attempted to sign in again, but the Switch-connected sessions did not recover reliably before I needed to finish the submission, That meant I couldn't record the complete live Mattermost workflow I had planned :(
Although, I want to be clear about the distinction -
I successfully observed Switch-connected Codex tool calls during development, The submitted illustrated demonstration, however, shows independently tested Proofline backend behavior, not a continuous successful Switch chat session
That's a limitation of this submission, and it's also an important lesson about building reliable agent workflows, Authentication, environment setup, permission requests, and session recovery are part of the engineering problem not just the AI prompt!
The engineering decision I'd keep
Even if I rebuilt Proofline from scratch, I would definitely keep the deterministic verification engine, Instead, I'd let it understand the human request, identify the relevant records, and propose changes.The backend would still enforce the actual business rules, The same applies to publication, An AI tool should not receive the same authority as a human manager simply because it can produce a convincing answer. Proofline also creates SHA-256 evidence receipts/history and maintains an audit history, These are useful mechanisms for identifying what was checked and recording the workflow!
What I'd improve next
So, If I continued developing Proofline, the next step wouldn't be adding another AI model, Instead, I'd integrate it with an actual inventory or delivery data source and replace the local manager PIN with proper organizational authentication, However, I'd also want durable transactional storage, stronger audit protections, and background monitoring for changes to published claims
On the Switch side, the improvements I'd most appreciate are pretty straightforward -
Clearer agent working-directory configuration
Better Windows executable and sandbox diagnostics.
Reliable recovery from revoked authentication sessions
A visible, enforceable per-agent usage budget
For somebody trying Switch, for the first time, my biggest advice is to test one read-only command end to end before designing a complicated agent workflow :) Alas, I learned that one the hard way!
Final thought
Building Proofline made me think differently about AI-assisted software, The challenge isn't only getting an agent to perform a task, It's deciding what the agent should be allowed to do, what the application must verify independently, and what happens when reality changes after a human decision, Thus, Proofline is still a prototype built with fictional operational data
But the idea behind it is something I'd like to keep exploring - A promise should remain public only while the evidence behind it remains true. That's Proofline for you, Thanks for reading!
Top comments (0)