Decision Receipt

• 

• 

• 

• 

• 

Inspiration

People usually remember what they decided, but not exactly what they expected or assumed at the time. Once the outcome is known, hindsight edits the story: uncertainty disappears, original assumptions become harder to recall, and every result starts to feel predictable.

Decision Receipt was built to preserve that missing moment. It turns the reasoning behind a decision into a compact artifact that can be revisited after reality provides an answer.

What it does

Decision Receipt follows one intentionally simple loop:

Capture → Lock → Review → Learn

The user describes a decision, expected outcome, and reasoning in one paragraph. The application structures that input into:

• The decision being made
• A measurable expected outcome
• One to three key assumptions
• A signal that would disconfirm the expectation
• The user's confidence
• A future review date

The user can edit every field before locking the receipt. Once locked, the original reasoning is preserved. When the outcome becomes knowable, the user reports what happened and compares it with the frozen expectation. The review checks each assumption against evidence while deliberately avoiding labels such as “good decision” or “bad decision.”

After multiple reviews, the Insights view surfaces cautious cross-receipt patterns. Every pattern cites the receipts that support it, stays within the available sample, and says when evidence is insufficient.

Why it is different

Decision Receipt is not another AI chat, journal, task manager, or decision adviser. It does not recommend what the user should choose. Its primary object is an immutable receipt: a falsifiable record created while uncertainty is still real.

The product separates decision quality from outcome quality. A sensible decision can have a poor outcome, and a careless decision can get lucky. Preserving the original expectation makes that distinction visible.

How it was built

The application uses Next.js, React, and TypeScript with Zod schemas at API and persistence boundaries. The Build Week MVP is intentionally local-first: receipts and reviews remain in browser storage, so judges need no account, database, credentials, or paid service.

Deterministic local engines power the default extraction, comparison, and evidence-linked pattern flows. Their output is visibly labeled Local analysis. The codebase also contains an optional OpenAI Responses API adapter with schema-constrained output; when configured, the UI labels genuine provider output as GPT-5.6. The app never presents deterministic output as a model response.

Optional email reminders can be scheduled through Resend. The core product works without entering an email address.

How Codex and GPT-5.6 were used

Codex with GPT-5.6 was the development partner throughout Build Week. It accelerated:

• Converting a locked product specification into a complete vertical slice
• Designing and implementing the responsive editorial interface
• Building schemas, route contracts, local analysis engines, persistence, and reminders
• Creating unit, component, API-contract, and browser-flow tests
• Diagnosing hydration, TypeScript, linting, routing, and responsive-layout issues
• Testing the judge journey, publishing the repository, and deploying the public build

The important product decisions remained human-owned: the hindsight-bias problem, the receipt-not-chat interaction, the Capture → Lock → Review → Learn loop, the no-advice boundary, and the local-first submission architecture.

Challenges

The largest challenge was creating a complete learning loop without requiring judges to wait weeks for a real outcome. Seeded historical receipts provide reviewed evidence immediately, while a due receipt demonstrates the comparison flow.

Another challenge was maintaining honest provenance after discovering that promotional Codex credits were not OpenAI API credits. Instead of disguising a fallback, the product makes its deterministic path first-class and labels every analysis source. This also made the judge experience faster, private, and zero-configuration.

Accomplishments

• A coherent end-to-end experience rather than a technical proof of concept
• A new artifact—the decision receipt—that is distinct from chat and journaling
• Structured capture, immutable locking, outcome review, and cited cross-receipt insights
• A responsive visual system designed for both desktop and mobile
• Ten passing automated tests plus production build validation
• A public, licensed repository and zero-credential deployed demo

What we learned

The most valuable AI product boundary was not adding more intelligence; it was deciding what the system must never claim. Decision Receipt structures and compares, but the user retains judgment. Evidence provenance, insufficient-evidence states, and source labels made the product more trustworthy and more distinctive.

What's next

The next version would add encrypted multi-device sync, optional accounts, export and deletion controls, confidence-calibration views for larger samples, and richer reminder delivery. The core receipt and review loop will remain intentionally small.

Built With

• codex
• gpt-5.6
• next.js
• openai-javascript-sdk
• playwright
• react
• tailwind-css
• testing-library
• typescript
• vercel
• vitest
• zod