Project Summary

Ready to Stand Behind is an original browser-based interactive case study examining how AI-assisted learning content becomes work a professional team can defend.

The viewer operates a short passenger-support prototype, examines what AI produced, reviews four problems found through human evaluation, compares the original and revised builds, and traces each documented finding to its supporting requirement or source.

I built the complete experience in custom HTML, CSS, and JavaScript without an authoring tool.

The Challenge

Most conversations about AI in learning design focus on production speed. The harder problem begins after the fast draft exists—when the work looks finished, reads well, and would survive a client demonstration, but nobody has yet asked what supports it.

A fictional transit agency, Alderline Transit, needs a short scenario to help station agents assist passengers during a route disruption. The service information is not the central performance problem. The challenge is what happens under pressure: staff want to give a distressed passenger a solution, and the most satisfying answer may be one they are not authorized to promise.

The initial AI-assisted build was polished, complete, and ready to show. It also contained four elements I could not have defended if a client had asked what supported them.

AI can help produce the work. Human judgment determines whether the team can stand behind it.

How This Differs from SHIFT 17 and The 4:47 Decision

SHIFT 17 examines whether responsible action survives operational pressure. The 4:47 Decision examines how a professional diagnoses a system from distributed evidence. Ready to Stand Behind examines how AI-assisted work becomes something a team can defend.

This is a viewer-operated case study rather than a scored simulation. It does not ask the viewer to make the design decisions. It makes the production process visible so the viewer can operate the prototype, compare its two states, examine what changed, and trace the evidence behind the revisions.

The transit scenario is the vehicle. It is not the subject.

My Role

I served as the learning experience designer, reviewer, developer, and production lead.

I defined the performance problem, created the fictional client context, established the evidence and accessibility requirements, designed the review architecture, directed the AI-assisted production process, evaluated the first build, made the final design decisions, and built and tested the interactive case study.

I also created the supporting documentation, including the production records, change rationale, accessibility verification, evidence traceability, quality-assurance record, and final readiness recommendation.

The Solution

The experience presents a complete AI-assisted production and review cycle.

Build v0.6 came together in a single AI-assisted pass that included draft dialogue, scenario alternatives, and a detour graphic. It passed a completeness review: every screen was present, every field was populated, and the scenario ran from beginning to end.

Human review then identified four problems:

• The agent offered a rideshare voucher that no approved source authorized.

• An AI-synthesized statement was presented as a direct employee quotation.

• The detour map’s alternative text was populated but did not communicate the information needed to use the map.

• The client-facing production description was accurate but omitted AI’s contribution, the human review process, and the assumptions that remained unconfirmed.

Build v0.7 revises those four elements while leaving the rest of the prototype unchanged. The unsupported promise is replaced with verified assistance and an escalation route through Operations Control. The synthesized statement is identified honestly. The detour map receives a complete text equivalent. The client-facing description explains how AI contributed and what human review changed.

The viewer can examine the work in three ways:

• Operate — Run the passenger-support prototype as a functioning 60-to-90-second experience.

• Compare — Switch the same prototype between its original and revised states.

• Trace — Open each finding to see the requirement or source supporting it.

The final recommendation is not approve or hold. It is proceed as a working review: present the revised direction, identify the unresolved assumption, and use the client meeting to confirm the requirement.

What Makes the Experience Distinct

The comparison isolates the design decisions

The original and revised builds are not separate interpretations of the assignment. They are two states of the same prototype.

Only the four reviewed elements change. Everything else remains consistent, allowing the viewer to see what each human design decision contributes without having to compare two unrelated products.

Polish is treated as a potential risk

The unsupported rideshare offer was one of the most persuasive moments in the first build. The passenger accepted it with relief, which made the promise feel like the correct response.

That emotional effectiveness increased the risk. The problem was not awkward writing or an obvious error. It was a polished moment teaching behavior that the approved materials did not authorize.

Accessibility is evaluated for meaning, not presence

The first build contained alternative text for the detour map: “Map of current detour.”

A completeness check could confirm that the field was populated. It could not determine whether a screen-reader user received the map’s essential service, transfer, and accessibility information.

The revision provides a complete text record rather than treating the presence of alternative text as proof of equivalent access.

Absence of evidence is allowed to remain visible

Alderline’s approved materials do not establish whether a frontline employee may offer transportation alternatives. The revised scene routes the question to Operations Control, which is consistent with the fictional brief, but the underlying procedure remains unconfirmed.

The experience identifies that limitation instead of converting an unsupported assumption into policy.

The verification process is also subject to review

The project does not present automated checking as conclusive simply because a test reports success.

During production, checks reported conditions as verified when those conditions were not fully true. Those failures became part of the project record because they demonstrate the same problem the case study examines: confidence, completion, and correctness are not interchangeable.

Research and Evidence Foundation

The case study distinguishes among fictional client requirements, approved project materials, accessibility requirements, external evidence, and design assumptions.

The supporting record preserves:

• what each documented finding was evaluated against;

• which requirement or source supported it;

• whether its authority was internal, external, or fictional;

• what changed between builds;

• why the revision was selected;

• which alternatives were considered or rejected;

• and what remained unresolved.

Where external evidence supports a finding, the experience identifies it. Where a rule belongs only to the fictional client environment, it says so. Where research failed to support a claim, that absence is documented rather than concealed.

Alderline Transit, its network, employees, dialogue, and service information were created for this case study. They do not represent a real transit agency, location, or operating procedure.

Key Contributions

• Performance-problem definition

• Fictional client and operational context

• AI-assisted production strategy

• Human review framework

• Evidence and requirement traceability

• Before-and-after comparison design

• Scenario dialogue and revision

• Accessibility evaluation and implementation

• Complete text equivalent for the detour map

• Production and change documentation

• Readiness recommendation

• Custom HTML, CSS, and JavaScript development

• Keyboard, focus, transcript, and reduced-motion support

• Quality-assurance and distribution review

AI in the Project

AI assisted with drafting, alternative generation, implementation code, consistency checking, testing, and production of the station photograph.

The production archive documents AI’s contributions, accepted and rejected production candidates, major human revisions, and the release quality-assurance record.

The design decisions remained mine: determining what the experience should examine, establishing what counted as acceptable evidence, evaluating the first build, deciding what needed to change, selecting the revisions, and determining what was ready to present.

Three moments from production make that division visible.

A verification check reported success while the condition was false. It compared the detour map with its text equivalent and reported full content parity. The test was matching a single word across entire files, so one stop’s elevator information satisfied it while three stops were still missing theirs.

A rename reported zero remaining instances while the old name remained visible. A find-and-replace operation searched every file and returned a clean result. The old wordmark remained on the screen because its letters were divided across separate elements and no complete string matched. It was found by examining the rendered work, not by searching the files.

A distribution manifest marked a restricted file as safe to share. Two packages contained files named README.txt. One was public; the other carried an internal restriction. Because the filenames matched, the restricted file inherited the public classification. That error could have exposed material that was not intended for external distribution.

Each problem was found by a person examining work that had already reported itself as verified. That is the central argument of the project occurring inside its own production process.

Value

Ready to Stand Behind demonstrates a disciplined approach to AI-assisted learning production: use AI to extend production capacity, then evaluate the result against evidence, authority, accessibility, representation, and client risk.

The approach transfers to any environment in which AI-generated work must move beyond internal experimentation and become something a professional team is prepared to present, implement, or defend.

It also demonstrates that responsible review does not always end with a simple approval or rejection. Sometimes the strongest recommendation is to proceed with the revised direction while clearly identifying the requirement that still needs confirmation.