-
-
Facility dashboard with building operations, work-order categories, and quick access to create a new request.
-
02-ai-input.png AI-assisted work-order input with exact location, equipment context, technician notes, and optional photo evidence.
-
03-human-review.png Editable GPT-5.6 work-order draft requiring explicit human review and confirmation before creation.
-
04-facility-memory.png Facility Memory identifies incident 3 within 30 days and links only semantically related equipment history.
-
05-evidence-to-action.png Evidence-to-Action separates reported facts, visible evidence, validated history, AI inference, and unknowns.
-
06-closed-work-order.png Completed and signed work order with closure details and a PDF protocol ready for export and sharing.
Inspiration
Facility teams often treat every maintenance report as a new, isolated ticket. Once a work order is closed, its context is no longer visible during the next incident. As a result, recurring equipment failures can be missed, unrelated maintenance can be mistaken for a pattern, and technicians may repeatedly address symptoms instead of investigating the root cause.
Maintenance reports also combine different kinds of information: what a technician reported, what is visible in a photo, what is known from an asset record, what happened in previous work orders, what the AI inferred, and what is still unknown.
I built New Tone to give facility teams a safer and more structured way to turn field reports into actionable maintenance work.
A technician sees one incident. New Tone sees the history of the equipment.
What it does
New Tone is an AI Facility Operations Copilot for managing buildings, floors, rooms, equipment, technicians, and maintenance work orders.
A technician can:
- select the exact building, floor, room, asset, and component;
- type or dictate a problem description;
- attach an optional equipment photo;
- choose a category and priority;
- ask GPT-5.6 to prepare a structured work-order draft.
The AI draft includes:
- an editable title;
- category and priority;
- a concise summary;
- observations;
- potential risks;
- clarifying questions;
- recommended checks;
- possible duplicate information;
- recurrence analysis;
- evidence classification.
The result is never applied automatically. The technician reviews and edits the draft before selecting Confirm and create.
After creation, the work order continues through the normal operational workflow:
NEW → IN_PROGRESS → CLOSED
The technician can assign the work, record completion details, sign the closed order, generate a PDF protocol, and share it.
Facility Memory
Facility Memory gives the selected piece of equipment a bounded operational memory.
For the exact selected asset, New Tone examines recent NEW, IN_PROGRESS, and CLOSED work orders from the previous 30 days. GPT-5.6 identifies which historical incidents are semantically related to the current report.
Unrelated work on the same asset is not automatically treated as recurrence.
In the demonstration scenario, the current pressure-drop and unusual-noise report is correctly recognized as incident 3 within 30 days. Two related closed incidents are included, while routine label inspection is excluded.
The application validates related work-order references and calculates the displayed incident sequence itself. Internal model-generated IDs are never shown to the technician.
Evidence-to-Action
New Tone separates every important statement by evidence source:
- Reported now — information provided by the technician;
- Visible in photo — information that can actually be observed in the image;
- Asset record — known facility and equipment context;
- Work history — validated related historical work orders;
- AI inference — explicitly tentative reasoning;
- Still unknown — missing or unconfirmed information.
This prevents an AI inference from appearing as a verified technical fact and makes uncertainty visible before the technician acts.
How we built it
The mobile application is built with Flutter and Dart.
The AI layer uses a stateless Go gateway that calls the OpenAI Responses API with GPT-5.6 and strict Structured Outputs.
The workflow is:
- The Flutter application collects the technician report, optional photo, exact asset context, and bounded work-order history.
- The request is sent to the Go gateway over HTTPS.
- The gateway validates input size, allowed values, identifiers, and history references.
- GPT-5.6 returns a response constrained by an explicit JSON Schema.
- The Go backend validates the decoded output again.
- The Flutter application opens an editable human-review screen.
- Nothing is created until the technician explicitly confirms the draft.
The OpenAI API key exists only in the backend environment and is never included in the Android application. The gateway does not persist descriptions, photos, history, or model responses, and the OpenAI request uses store: false.
Manual work-order creation remains available when AI is unavailable or unnecessary.
Codex was used throughout Build Week to implement, test, review, and harden the Flutter and Go changes. It helped with client/server schema alignment, regression tests, Facility Memory validation, deployment preparation, production debugging, code review, and public documentation.
The architecture and final product decisions remained human-directed.
Challenges we ran into
One of the main challenges was keeping the Flutter models, Go validation, and OpenAI Structured Outputs schema exactly aligned. A field accepted by one layer but rejected by another could break the complete workflow.
Another challenge was separating two different concepts:
- a possible duplicate open request;
- a recurring historical equipment pattern.
Duplicate detection concerns potentially overlapping active work. Facility Memory concerns recurrence across the selected asset's recent history. These signals had to remain independent.
We also needed to prevent invalid or invented historical references. Related work-order IDs are therefore restricted to IDs actually supplied in the request and are validated again after the model response is decoded.
Photo analysis required similar caution. The system must distinguish what is truly visible from what cannot be confirmed from an image, such as an internal pressure loss, unusual sound, or hidden component failure.
Finally, the AI workflow had to remain useful without becoming autonomous. Every generated field is editable, manual creation remains available, and explicit confirmation is mandatory.
Accomplishments that we're proud of
- Built a complete AI-assisted work-order flow rather than a separate chat interface.
- Added voice-recognized description input and optional image evidence.
- Implemented strict GPT-5.6 Structured Outputs through a stateless Go gateway.
- Created Facility Memory for exact-asset recurrence detection.
- Correctly excluded unrelated maintenance from the demonstrated recurrence sequence.
- Created an Evidence-to-Action model that separates facts, history, inference, and unknowns.
- Preserved mandatory human review and manual fallback.
- Integrated the AI result with assignment, execution, closure, signature, and PDF export.
- Completed Flutter analysis, automated tests, Go tests, static checks, production deployment checks, and real Android-device testing.
- Preserved the pre-Build Week baseline in Git while documenting the competition work separately.
What we learned
The most valuable AI features are embedded inside an existing operational workflow rather than added as a disconnected assistant.
Structured output is only the beginning. A reliable implementation also needs input bounds, identifier validation, server-side output validation, safe failure behavior, visible uncertainty, and a clear human decision point.
We also learned that equipment history becomes much more useful when the system can distinguish a genuine recurrence from unrelated work performed on the same asset.
Codex was especially effective for repeatedly checking implementation details across Flutter, Go, schemas, tests, deployment configuration, and documentation. Human review was still essential for architecture, safety boundaries, product behavior, and final acceptance.
What's next for New Tone
The Build Week version is a working prototype and demonstration.
The next production steps are:
- per-user authentication and authorization;
- role-based access control;
- a shared cloud database;
- durable audit history;
- managed secrets;
- centralized asset and work-order synchronization;
- production monitoring and rate controls;
- evaluation with larger real-world facility datasets;
- integrations with existing facility-management and ticketing platforms.
The long-term goal is simple:
Give every piece of equipment a memory.
Log in or sign up for Devpost to join the conversation.