Inspiration
We ran into this problem while building the entry itself. A non-technical owner wanted to discuss the event and approve a topic before construction, but an AI workflow began building a plausible fallback idea before that direction had actually been approved.
That exposed a broader failure mode: an AI can efficiently complete the wrong project when discussion, interpretation, approval, construction, and proof are treated as the same thing.
What it does
SSS Project Sentinel is a local-first Codex plugin that keeps a non-technical owner's approved requirements traceable before, during, and after AI-led construction.
Before construction, GPT-5.6 preserves the owner's original words, restates candidate requirements in plain language, and surfaces semantic concerns. Only explicit owner confirmation makes an item binding.
During construction, every work item must reference a stable approved requirement identifier. After construction, every completion claim must link to collected evidence. A dependency-free local checker produces a red, yellow, or green result and blocks unsupported completion claims.
Engineering acceptance stays separate from the owner's experience judgment. If the work passes technically but feels wrong, Sentinel preserves the truthful engineering result and creates an unconfirmed candidate supplement for the next cycle. It cannot enter construction until the owner confirms it.
How we built it
We used Codex and GPT-5.6 throughout product discovery, requirement clarification, plugin and skill design, contract design, implementation, test generation, failure repair, documentation, and submission preparation.
GPT-5.6 handles language judgment and ambiguity. A local Python validator checks recorded approval, stable identifiers, plan coverage, forbidden scope, evidence, and final acceptance status. The model cannot approve its own interpretation or override the deterministic checker.
The project was created in a new isolated repository during Build Week. The wider problem was informed by prior experience coordinating AI work, but the submitted plugin, contract, validator, examples, reports, tests, and demo were implemented during the event.
Challenges
The hardest design question was how to respect ordinary human language without pretending that an AI confidence score equals consent. We solved this with explicit states: confirmed, conditional, needs clarification, and excluded.
The second challenge was making failure useful to a non-technical owner. The system must explain what is missing without asking the owner to inspect source code, logs, or specialist project-management tools.
Accomplishments
Working Codex plugin with a before/during/after workflow. Stable traceability from original wording to requirement, work item, and evidence. Explicit owner approval and append-only change semantics. Dependency-free local validator and bilingual HTML report. Synthetic blocked, repaired, and experience-gap judge cases. 23 product tests, 5 provenance isolation tests, and 14 session-preflight tests. Real GPT-5.6 judge-session evidence and a real feedback Session ID. No separate API key, hosted database, or real user data required.
What we learned
AI reliability is not only a question of model intelligence. It is also a question of authority and provenance: who said what, how it was interpreted, who approved it, what was built, and what can be proven. A polished completion message is not evidence.
Owner's field assessment
The non-technical Owner who defined and tested the product confirmed that Sentinel reduces the risk of approved requirements being omitted or silently reinterpreted during AI-led work. It also lets the Owner review requirement coverage and evidence instead of personally performing engineering acceptance. Keeping engineering acceptance separate from experiential acceptance prevents a technically correct result from being treated as final when it still feels wrong.
The Owner also identified clear limitations. The benefit is less visible in small or short-lived projects. Sentinel is not a conventional interface-first application; its value appears mainly through fewer omissions, clearer status, and more trustworthy completion claims. Explicit confirmation reduces semantic drift but cannot guarantee that every interpretation is correct. The strongest benefit is expected in long-running, multi-task AI projects where requirements and decisions accumulate over time. After the MVP was completed, its core method was applied in a real planning and recovery workflow for such a project, producing stable confirmed-requirement, candidate, and validation records. This is early field evidence, not yet an end-to-end deployment across the project's full construction lifecycle.
What's next
Future versions could add interactive owner approval cards, signed change histories, adapters for issue trackers and CI systems, and optional team review. Those are intentionally outside this Build Week MVP.
Log in or sign up for Devpost to join the conversation.