Bad Day Receipt

Inspiration

Most software has a hidden prerequisite:

You must be functioning well enough to use it.

On a difficult day, that prerequisite becomes cruel.

The insurance email still needs an answer. The medical form is still due. The bill, appeal, appointment, or consequential message does not disappear simply because the person facing it has less attention, working memory, decision capacity, or emotional energy available.

The obligation remains.

The interface continues demanding full capacity as though nothing happened.

Bad Day Receipt began as a way to make invisible effort visible. It turns interruptions, care work, emotional labor, and acts of survival that ordinary records leave out into a physical feeling receipt.

Its central recognition is:

This day required more than the record shows.

But recognition alone was not enough.

During OpenAI Build Week, I asked a harder product question:

What practical consequence should that receipt have?

The answer became Carry Forward:

The next task should not continue demanding full capacity.

Before Build Week, Bad Day Receipt documented what the day cost.

During Build Week, I built the system that allows one remaining obligation to respond to that cost: Carry Forward, the Interaction Budget, the GPT-5.6 task compiler, application level validation, One Thing Mode, graceful failure recovery, and their integration into the completed receipt experience.

What it does

Bad Day Receipt helps a person document effort, interruptions, care work, and survival that a normal productivity record ignores.

Once the receipt is complete, the user reaches three equally valid endings:

1. Keep the receipt
2. Let the receipt go
3. Carry one thing forward

Nothing else is required. The receipt is already complete.

When the user selects Carry One Thing Forward, they name one remaining obligation and may optionally provide the source material it depends on.

They then declare an Interaction Budget by choosing what the next interface should ask less of:

1. Show me one step at a time
2. Give me fewer decisions
3. Protect the progress I have already made
4. Defer work that is genuinely optional

These are explicit user requests.

The application does not diagnose the person, detect emotion, estimate capacity, or create a hidden psychological profile. The user states what would help. The interface responds to that request.

GPT-5.6 compiles the obligation, source material, and selected constraints into a strict typed task plan.

The application validates that plan and renders it through a fixed React component system as One Thing Mode.

One Thing Mode presents the next necessary step while preserving access to:

• The complete plan
• An explanation of why the view was adapted
• Editing controls
• Recovery options
• Cancellation and exit
• The original completed receipt

The result is not a chatbot.

It is a temporary, task specific interface built around one obligation and one user declared Interaction Budget.

The reference experience helps someone prepare an appeal for a difficult insurance denial. The user identifies the desired outcome, reviews facts supported by the source material, makes only the decisions that are genuinely necessary, prepares a bounded draft, and reaches final review without surrendering control of the external action.

Nothing is sent automatically.

The product prepares the work.

The person remains in control.

Why GPT-5.6 is necessary

The product cannot predesign a separate interface for every possible obligation.

Real tasks arrive as unstructured material. They may contain instructions, irrelevant details, missing information, meaningful decisions, optional work, deadlines, facts that must be preserved, and content requiring drafting or review.

A deterministic workflow cannot reliably interpret all of those variations.

GPT-5.6 acts as a constrained task compiler.

It can:

• Identify the real goal and completion condition
• Separate essential steps from optional work
• Extract facts supported by supplied material
• Identify decisions that genuinely require the user
• Prepare bounded draft content
• Convert an unstructured obligation into approved task step types

Its authority is deliberately limited.

GPT-5.6 cannot:

• Choose the user’s Interaction Budget
• Diagnose emotion or estimate emotional severity
• Browse accounts or retrieve private information
• Send messages or submit forms
• Make purchases or delete information
• Perform irreversible actions
• Control routing, layout, storage, navigation, or interface behavior

The model proposes structure.

The application controls behavior.

How I built it

Bad Day Receipt is built with:

• React 19
• TypeScript
• Vite 8
• OpenAI Responses API
• GPT-5.6
• Structured Outputs
• Vitest
• Playwright
• axe-core
• Local browser persistence
• A progressive web app service worker
• Vercel

Carry Forward creates a strict boundary between model interpretation and application authority:

User selected obligation
        +
Optional source context
        +
User declared Interaction Budget
        ↓
GPT-5.6 task compiler
        ↓
Strict TaskPlan JSON
        ↓
Application validator
        ↓
Typed React components
        ↓
Stable One Thing Mode

No model generated HTML enters the interface.

Model output cannot control routing, layout, persistence, navigation, or application actions. Every proposed task plan must pass application owned validation before it can be rendered.

The validator enforces rules including:

• Only approved step types may be used
• Choice counts must remain bounded
• The plan must define a concrete completion condition
• Extracted evidence must match the supplied source material
• Executable markup is rejected
• External side effects are prohibited
• Malformed, incomplete, or unsupported output fails closed
• Editing, cancellation, complete plan access, and exit remain outside model control

The goal is not merely a smaller interface.

It is a Minimum Necessary Interface:

The smallest complete set of information, decisions, and actions required to finish one user selected task.

Minimum does not mean incomplete.

It does not mean hiding risk, withholding context, or making decisions for the user.

It means removing avoidable demand while preserving agency.

Privacy and temporary state

Task context is sent only after the user explicitly approves assisted compilation.

The OpenAI API key remains server side. Raw task material is excluded from receipt history, receipt exports, and analytics.

Temporary task state has its own lifecycle. It can be cleared immediately by the user and expires automatically.

Graceful failure

If GPT-5.6 is unavailable, refuses the request, times out, returns incomplete output, or produces a plan that fails validation, the invalid plan is never rendered.

The application preserves the task and opens a manual one task workspace instead.

AI failure should not become product failure.

The completed receipt also remains valid through every Carry Forward interruption.

Ritual failure does not become receipt failure.

Compiler failure does not become product failure.

Changing your mind is not treated as user error.

How I used Codex

I used Codex throughout the Build Week implementation, not simply to generate isolated pieces of code.

The project already contained a production receipt machine with its own state, persistence, recovery, accessibility, and artifact systems. The challenge was to introduce an ambitious AI workflow without destabilizing the product that already worked.

I first used Codex to inspect and map the existing architecture. We identified the correct boundaries for receipt completion, routing, persistence, recovery, temporary task state, and model authority.

I then used Codex to:

• Scaffold the Carry Forward modules
• Translate the interaction contract into TypeScript types and schemas
• Build application validators and rejection paths
• Create representative and adversarial fixtures
• Trace refresh, cancellation, expiry, and storage failure behavior
• Audit keyboard, screen reader, reduced motion, and viewport behavior
• Review privacy boundaries and server request handling
• Strengthen regression tests and release verification
• Investigate failures across GitHub Actions, Vercel, and browser tests
• Verify the production implementation against the Figma engineering contract

Codex accelerated architecture work, implementation, investigation, testing, debugging, and verification.

The defining product decisions remained human decisions:

1. Declared load instead of detected emotion
2. No model tools for the compiler
3. No automatic submission
4. Typed plans instead of generated interfaces
5. Stable layouts instead of continuous adaptation
6. Explicit approval before the interface changes
7. Temporary task data with a clear ending
8. Graceful manual recovery when AI is unavailable
9. Three valid endings with no pressure to continue

Codex helped me build the system faster.

It did not decide what kind of system deserved to exist.

Challenges I faced

Reducing demand without reducing agency

The hardest problem was not generating a task plan.

It was making the interface ask less without concealing important information or quietly making decisions on the user’s behalf.

A minimal interface can quickly become patronizing, incomplete, or dangerous.

One Thing Mode therefore preserves access to the complete plan, explanations, editing, cancellation, recovery, and exit.

The model can suggest structure, but it cannot remove the user’s authority over the task.

The goal is not the fewest visible elements.

It is the smallest complete path.

Adapting without emotional surveillance

Adaptive software is often framed around detecting the user.

I deliberately chose another direction:

Declared load, not detected emotion.

Bad Day Receipt uses no camera, biometric signal, facial analysis, sentiment score, attention detector, behavior based capacity score, or permanent psychological profile.

The person does not need to prove that they are struggling.

They simply state what the next interface should ask less of.

That request is enough.

Making Structured Outputs safe to render

A valid JSON shape does not guarantee a responsible or useful plan.

A plan may satisfy its schema while still omitting a necessary action, inventing an unsupported fact, deferring work that is essential, or defining completion too vaguely.

I therefore separated machine enforceable invariants from semantic quality evaluation.

Structured Outputs constrain the plan’s shape.

Application validators enforce product rules.

Representative fixtures, adversarial testing, and human review address whether the resulting path is complete, grounded, and useful.

Structured output creates a reliability boundary.

It does not remove the need for product judgment.

Integrating AI without creating another chatbot

The AI needed to contribute something the application could not produce deterministically while remaining subordinate to the product system.

That tension produced the project’s central engineering principle:

The model proposes structure. The application controls behavior.

GPT-5.6 does not become the product.

It performs one bounded act of interpretation inside a product designed to contain it.

Preserving physical and emotional continuity

Carry Forward could not feel like a separate AI tool bolted onto the receipt.

The completed receipt remains mounted while the user chooses what happens next. The same receipt can be kept, released, or extended.

Carry Forward transforms a user designated remainder into a Field Transfer before entering the quieter One Thing Mode runtime.

The user’s decision changes what the same object does.

That continuity became both a design requirement and an engineering invariant.

Accomplishments I am proud of

I am proud that Bad Day Receipt uses AI to change the interface rather than merely adding another conversation box.

I am proud that the system reduces decision load without reducing agency.

I am proud that the compiler has no tools, performs no external actions, and cannot directly control the interface.

I am proud that the experience remains useful when assisted compilation fails.

I am proud that the completed receipt remains valid through interruptions, cancellations, storage failures, and compiler failures.

I am proud that Keep, Let Go, and Carry Forward are treated as equally complete outcomes. The user is never pressured to transform recognition into productivity.

Most of all, I am proud that the product treats reduced capacity as an interface condition rather than a personal failure.

The complete loop is:

Recognition → Agency → Relief → Closure

The receipt says:

What happened mattered.

Carry Forward asks:

Given that reality, what should the next task demand less of?

What I learned

I learned that humane adaptation does not require surveillance.

Asking someone what would help can be more respectful than attempting to infer it.

I learned that the smallest interface is not necessarily the safest interface. A Minimum Necessary Interface must contain the smallest complete path, not merely the fewest visible elements.

I learned that Structured Outputs are the beginning of a reliability boundary, not the end. Product specific validation, recovery behavior, and human review still matter.

I learned that reversibility, stable layouts, explicit approval, progress preservation, and graceful failure are not secondary polish.

They are part of the product’s emotional infrastructure.

I also learned that AI can become more useful when its authority is intentionally reduced.

The question is not only:

What can the model do?

The more important question is:

What should the model be allowed to decide?

What is next

The Build Week version proves one complete vertical slice around difficult personal administration.

Next, I would expand the task library to additional consequential workflows such as:

• Medical bills
• Appointment preparation
• Benefit appeals
• Difficult messages
• Forms
• Administrative decisions

I would add more representative and adversarial evaluations, conduct user testing around Interaction Budgets, and study which constraints meaningfully reduce abandonment without hiding necessary context.

I would also explore how the Minimum Necessary Interface pattern could become a reusable development system for products that need to remain usable during stress, fatigue, grief, illness, overload, or interruption.

The larger goal is to develop affective interface engineering:

Principles, patterns, tools, and emotional infrastructure for software that remains humane under pressure.

Bad Day Receipt is one working example of what that can look like.

Software usually asks people to continue as though nothing happened.

Carry Forward lets the next task respond.

Built With

• axe-core
• codex
• gpt-5.6
• node.js
• openai-api
• playwright
• react
• responses-api
• structured-outputs
• typescript
• vercel
• vite
• vitest
• web-storage-api
• zod