Inspiration
Workplace decisions often happen with partial information, time pressure, and consequences for other people. We wanted to create a learning experience that gives people room to think carefully before seeing an AI perspective.
Problem
Many AI experiences start by giving an answer. That can skip the learner’s own reasoning. In a workplace situation, the important work is often distinguishing facts from assumptions, identifying the protected outcome, considering stakeholders and risks, and verifying what is allowed before acting.
What it does
Capability Engine presents one prepared synthetic workplace situation. It guides a learner through required analysis prompts, saves their draft in the browser, asks them to review and lock their analysis, then provides an independent GPT-5.6 perspective for comparison. The learner can view DiJi reference content, reflect, and complete the learning session.
How it works
The learner first analyzes a report-delivery problem caused by a company email failure shortly before an internal deadline. After every required prompt is complete, the learner confirms submission; the analysis becomes immutable. Only then can the app call GPT-5.6. The server sends canonical case ID, version, locale, and a request ID—not learner answers, identity, reflection, or score data. The resulting structured perspective supports comparison and reflection without a score or verdict.
How we built it
We built a Next.js and React web application with TypeScript, Zod validation, Tailwind CSS, and a Node.js API route. The browser-local session preserves draft, locked analysis, AI snapshot, comparison, reflection, and completion state in the current browser. The server validates a compact canonical request, loads configured case evidence and reasoning contracts, calls the OpenAI API, validates the structured response, and exposes recoverable errors safely.
How we used GPT-5.6
GPT-5.6 creates an independent CORE situation analysis of the canonical synthetic case after the learner has locked their work. It does not receive or read the learner’s analysis before producing its output. The request is bounded by configured reasoning skills, static knowledge, guardrails, locale instructions, and a structured output contract. Its perspective is used for comparison and reflection, not as an absolute grader.
How we used Codex
Codex accelerated implementation of the architecture, learner-flow state transitions, API integration, schema validation, fallback and error handling, tests, documentation, validation, and deployment preparation. Humans retained decisions about the learning philosophy, scope, synthetic case, DiJi content, AI boundaries, privacy and security choices, and final acceptance.
Human decisions and AI boundaries
The demo case is synthetic and does not use employer or customer data. The learner thinks first and their submitted analysis is locked before AI is available. GPT-5.6 sees only the canonical case inputs, never learner answers or identity. The product does not score, rank, or declare a correct answer. DiJi is curated reference content, not an autonomous expert, chatbot, or grader.
Challenges we faced
The central challenge was making the AI comparison useful without turning it into an answer key. We also needed to keep the server request minimal, preserve a reliable learning state across refreshes, validate structured AI output, handle temporary failures safely, and make the difference between live model output and deterministic demonstration fallback transparent.
Accomplishments
We delivered a public working vertical slice: landing page, curated case selection, required learner analysis, draft persistence, review and immutable lock, independent GPT-5.6 analysis, structured comparison, DiJi reference content, reflection, Learning Completed, automated tests, and production deployment.
What we learned
AI learning design benefits from clear boundaries. Keeping learner input out of the AI request preserves an independent perspective. Structured contracts, validation, transparent fallback behavior, and non-scoring language are as important as the model call. A small, honest vertical slice made the learning loop testable end to end.
What existed before Build Week
Before Build Week, there was professional problem observation, an early Capability Engine concept, learning philosophy, methodology, and planning material. These informed the direction but are not presented as a pre-existing application.
What was built or meaningfully extended during Build Week
During Build Week, the repository history records the working vertical slice: the human-first learner flow, submit and lock state, independent GPT-5.6 analysis, structured comparison, DiJi guidance, reflection, completion, server-side validation and fallback, automated tests, public deployment preparation, and judging documentation.
Known limitations
This Build Week MVP has one synthetic curated case and browser-local persistence only. It has no accounts, server-side learner records, quiz, scoring, email summary, user-contributed situations, retrieval/RAG, personalization, recommendations, learning paths, or multi-case library. The shared 7:33 DiJi reference video has no captions or transcript in this release.
What's next
Next steps are to validate additional cases with users, establish privacy and retention requirements before persistent records, and then evaluate reviewed contributed cases, knowledge operations, learning paths, accessibility improvements, and broader capability evidence. These are future work, not current MVP claims.
Built With
- codex
- eslint
- gpt-5.6
- next.js
- node.js
- openai-api
- react
- tailwind-css
- typescript
- vercel.app
- vitest
- zod
Log in or sign up for Devpost to join the conversation.