Hi everyone,
I’m excited to share that my entry, FoxOps, has been selected as a Finalist for the 2026 Challenge.
Why I Built FoxOps: Standardizing the “Digital Floor”
In my 14 years as a Mechatronics Engineer, I learned that a machine is only as good as its documentation. Without a clear Standard Operating Procedure (SOP), even the best hardware fails.
I noticed that in the digital world, we build amazing things, but the “How-To” often stays locked in someone’s head or hidden in messy notes. I created FoxOps to automate the generation of these SOPs—ensuring that every digital process is documented with the same rigor we use on a factory floor.
The “How”: Turning Chaos into Industrial SOPs
Here is how I used Industrial Logic on the Make canvas to turn raw data into structured documentation:
1. The “Intake Valve” (SOP Input)
-
The Process: Whether it’s a transcript or a rough note, I treat input like raw material. I use Webhooks as “Sensors” to detect when a new process needs documenting.
-
Why it matters: It ensures that “knowledge capture” happens the moment the work is done, not three weeks later when the details are forgotten.
2. The “Refinery” (AI Logic & Filtering)
-
The Process: I use Filters as “Check Valves.” Before the AI generates the SOP, the data must pass a quality check. Is the input complete? Are the steps clear?
-
Why it matters: In engineering, you don’t feed bad raw materials into a machine. These filters ensure the final SOP is high-signal and fluff-free.
3. The “Assembly Line” (Structured Output)
-
The Process: I use Routers to branch the documentation into different formats. One “path” might create a technical manual, while another creates a quick-start checklist.
-
Why it matters: Just like a factory has different stations for different parts, FoxOps delivers the right documentation to the right person automatically.
4. The “Safety Circuit” (Error Handling)
-
The Process: If an API times out during the generation process, I use Error Handler Routes (Break/Resume).
-
Why it matters: Generating an SOP shouldn’t break because of a 5-second server glitch. The safety circuit ensures the “paperwork” gets finished even if the “digital conveyor” hiccups.
Why This Matters for the Community
Most of us hate writing documentation. We’d rather be building. FoxOps is my way of making sure the “Human Side” of automation (the SOPs) is just as reliable as the “Digital Side” (the code).
It’s about moving from “I think this is how it works” to “Here is the blueprint for our success.”
The Concept: Instead of just using Make for simple tasks, I engineered it as a “Self-Healing Host” for technical infrastructure.
The Architecture:
-
Engine: Make.com + Custom MCP Server
-
Logic: Deterministic SOP Execution (Not just LLM guesses)
-
Performance: Reduced incident response time from ~45 mins to 1.2 seconds.
Live Demo: I’ve opened the FoxOps Command Dashboard for the community to audit during the judging period. You can see the live telemetry and “Self-Healing” logs here:
Foxops Page (Note: Use the “Auto-Inject” button on the login page to access the demo deck.)
I’d love to hear your feedback on the architecture. Good luck to all the other finalists!
— Frank Abalos Systems Architect