CS-03 Red Cross Disaster Relief Platform — Case Audit

Gating Status: P0

I fetched the live URL. The server returns HTTP 200 with the complete case study HTML before the client-side JavaScript redirect fires. The gate checks localStorage for a pf_access_v1 key and redirects unauthenticated visitors to /login.html. But the redirect happens after the server has already delivered your most sensitive positioning content to the browser. Hero, mockups, six design decisions, metrics, the 2026 agentic redesign section.

Same vulnerability pattern I flagged on the "What Do You Count" essay. Same severity.

The login page compounds it: the password hash is hard-coded in client-delivered JavaScript using crypto.subtle.digest('SHA-256', ...) and compared against a CORRECT_HASH constant visible in the page source. Anyone with a browser inspector can read it.

You are sending this page to hiring managers at companies where you want to demonstrate that you understand system-level trust architecture. The page itself contradicts that claim.

What the Page Currently Contains

The hero opens with "Designing for the worst day of someone's life." Role line: "Product Design Director / GM · 0→1 Build." Team: one designer, one researcher, one PM, two engineers, two BAs. Hero metrics: six months to national deployment, $847K disbursed during active events, six legacy systems consolidated into one, 1,689+ cases in the first two weeks.

Below the hero, the page frames the operating environment: federal disaster declarations, mass displacement, surge volunteers, federal audit pressure, six disconnected tools. Then six design decisions organized by role: Field Volunteer intake, Caseworker case detail, Caseworker outreach, Supervisor eligibility, Finance Officer payments, Program Director command. A closing 2026 section reframes the same problems as agentic-system design challenges.

The page is strong. Several sections are genuinely excellent. And it reads, on first pass, as a brilliantly executed design project led by a senior IC with unusual operational awareness.

It does not yet read as a GM-level build.

GM scope means you owned the product mandate, the delivery path, and the organizational tradeoffs. The design decisions lived inside that accountability. The evidence that you operated as a GM is on this page. The frame around the evidence still presents you as a designer who happened to touch GM-shaped problems. That gap is what this audit is about.

Criterion 1 — GM Scope in the Opening

Present but weak.

The GM claim exists in the role metadata line. The hero says you "led design and delivery." Both are true signals. Both are in the wrong place.

A hiring manager scanning this page forms their first impression from the headline and the first narrative paragraph. The role metadata line comes too late. "Designing for the worst day of someone's life" is a compelling emotional frame. It tells the buyer this is high-stakes, mission-critical work. It doesn't tell them you owned the mandate. By the time they reach the role line, they've already filed this as "strong designer, important project." You're fighting to upgrade that impression rather than setting it correctly from the start.

Keep the emotional headline. Move GM scope into the first narrative sentence so it lands before the buyer's mental model solidifies.

Three things the current opening doesn't do that this sentence does: it puts "owned" before "designed," it names the team size to signal operating accountability, and it sequences the outcome as proof of the mandate rather than proof of the craft. The craft evidence follows, but the frame has to land first.

Criterion 2 — Constraints as the Design Problem

Present and effective. One upgrade available.

Strongest section on the page. The framing that the design problem was the operating environment, full stop, is exactly right. Federal disaster declarations, mass displacement, untrained volunteers, slow networks, six incompatible tools, federal audit pressure. The line "Every process bottleneck was a system failure" successfully reframes constraints from background into the core design challenge. This section works. Don't restructure it.

The upgrade: the section describes the constraint environment vividly but doesn't name the GM-level tradeoff you had to manage inside it. One sentence would close that gap.

That sentence turns a vivid situation description into a decision framework. It tells the buyer you were making allocation decisions about where complexity lives inside a difficult environment. A small addition to an already-strong section.

Criterion 3 — Complexity in the System, Simplicity in the Interface

Present and effective.

The principle appears explicitly in the approach grid. Decision 01 (Field Volunteer intake) illustrates it concretely through a specific design decision the reader can evaluate: three fields instead of eight, auto-selection of program type, progressive disclosure, FEMA address verification, duplicate detection, rule-locking around Grey Sky versus Blue Sky assistance logic. Specific enough that a buyer can see the judgment. You show what was hidden, what was automated, and what error cascade the design prevented.

One of the few places on the page where the systems-design thinking is fully visible through a specific artifact decision. Protect it.

Strengthen the caption by making the operational cost of the alternative explicit:

That last line matters because it tells the buyer you designed for a failure mode the user would never see but the organization would pay for. And it directly enables the surge-readiness claim I'll address in Criterion 5: this is also why untrained volunteers could use the platform without training. Three fields and auto-selection didn't reduce complexity. They made training unnecessary by making wrong choices structurally impossible.

Criterion 4 — Three-Role Architecture Resolution

Present but weak. And there's a positioning inconsistency to resolve.

The page shows five role-specific surfaces: Field Volunteer, Caseworker, Supervisor, Finance Officer, Program Director. It says "Every role sees the same record." The six decisions walk through each role's view. But the architecture itself, the model that unifies these roles around a shared case record with permissioned decisions and audit events, is never named as a design problem or shown as a resolved system.

The buyer sees six well-designed screens. Without the architecture, the systems judgment that produced those screens stays invisible.

Second problem. Your published metrics say "3 roles unified." The walkthrough shows five distinct role surfaces. A buyer who notices will wonder whether you're simplifying for narrative convenience or whether the role model is genuinely more complex than the summary suggests. Either answer is fine, but the mismatch needs to be resolved on the page. If Field Volunteer, Caseworker, and Supervisor are the three core operating roles and Finance Officer and Program Director are permissioned extensions of the admin layer, say that. If the architecture actually unified five distinct roles, update the metric. The buyer who catches the discrepancy will read it as either imprecision or inflation, and neither serves you.

Add a short architecture section before the six decisions. Give the buyer the model before the screens:

Criterion 5 — Surge-Ready Design

Present but weak.

The claim is clear: "10× normal volume from day one," "No degradation," "No retraining required." Strong outcomes. The enabling decisions are scattered across the six role sections: progressive disclosure, one record, embedded FEMA documentation, urgency bars, batch approval, queue routing, command visibility. They're never gathered into a causal argument. The buyer sees the claim and the decisions separately. They have to do the synthesis themselves.

At this level, the buyer won't do that work.

Add a "What made 10× possible" block after Decision 06 or before the outcome metrics. Six bullets, each connecting a design decision to a surge-absorption mechanism:

• Three-field intake with auto-selected program type meant untrained surge volunteers could open cases without training, because the interface eliminated the decisions that required expertise. This is the "zero retraining" claim made auditable.
• Pre-selected disaster context reduced volunteer decisions at intake, removing the error cascade described in Decision 01.
• One case record eliminated cross-tool reconciliation during handoffs.
• Queue-based routing replaced supervisor case hunting under load.
• Audit fields captured during transactions, not in a separate compliance step.
• Director dashboards exposed cases, staff, funds, and compliance in one view, eliminating the reporting lag that creates decision delay during surge.

The first bullet matters most. The 10× claim has two legs: system architecture that absorbed volume, and interface learnability that absorbed untrained users. The architecture leg is impressive. The learnability leg is the one that proves GM-level design judgment, because it means you designed the intake to be structurally impossible to misuse rather than relying on training that wouldn't exist during a disaster surge. A design decision with organizational consequences. Name it.

Criterion 6 — Outcome Metrics and Timeline Context

Present but weak.

The metrics are strong and prominently placed: six months, $847K, six systems to one, 1,689+ cases, 98.7% FEMA compliance. The problem is that "six months" sits as a number without context. A buyer who has never shipped a federally constrained national platform doesn't know whether six months is fast, normal, or miraculous.

It's miraculous. You need them to know that.

Add a compact delivery-context line near the hero stats. One sentence that names what had to happen inside those six months:

That last clause, if true, is the detail that makes six months land. If the platform was handling real disaster cases before the end of the six-month build, say so. You shipped incrementally into a live operating environment under federal oversight. Speed under consequence. The number needs the scope to land.

Priority Stack

Ordered by impact on your regulated-platform and mission-critical tier positioning:

1. Fix the gate. The page delivers your most sensitive case content to unauthenticated requests. Every other recommendation is secondary until the page is actually protected. Server-side auth. This week.
2. Opening sequence. Move GM scope into the first narrative sentence. The buyer's mental model forms in the first five seconds. Right now those five seconds say "important project, strong designer." They should say "owned the mandate, built the system, shipped nationally in six months."
3. Architecture bridge. Add the role-architecture model before the six decisions. Resolve the three-role vs. five-role discrepancy. Without the bridge, the buyer sees six good screens. With it, they see the systems-design judgment that produced them.
4. Surge causality. Connect the 10× claim to the enabling decisions, including the learnability argument that makes "zero retraining" credible. The evidence is already on the page. Gather it into one scannable block that makes the mechanism visible.
5. Timeline context. One sentence that names what "six months" contained. The number needs the scope.
6. Constraints tradeoff sentence. One addition to an already-strong section. Low effort, meaningful upgrade to the GM read.

The Agentic Section — Placement and Versioning

The 2026 "If I were building this today" section reframes the disaster-response problems as agentic-system challenges: surge load, eligibility complexity, multi-role coordination, federal compliance, client portal gaps, call-center errors, recovery after disbursement. Smart positioning for the AI-native tier.

It sits at the bottom of the page. After the buyer has already formed their impression.

Since this page is already gated (or will be, once you fix the gate), you have a practical decision to make. Two options:

Option A: Two versions. One for regulated-platform buyers (Maven, Abridge, Mercury) where the agentic section stays at the bottom as a forward-looking bonus. One for AI-native buyers where a condensed version of the agentic reframe surfaces as a callout after the architecture bridge, before the six decisions. The buyer who cares about agentic design will scan past six role-specific UI walkthroughs to find it at the bottom. Don't make them.

Option B: One version, different placement. Move a short agentic callout up after the architecture bridge in the single version, with a link to the full section at the bottom. This works if you don't want to maintain two pages, but it slightly dilutes the constraint-dissolution narrative for regulated-platform buyers who don't care about the agentic angle yet.

My recommendation: Option A. You're already sending this page selectively to specific buyers. Two versions costs you an hour. Sending the wrong frame costs you the read.

The page is close. The evidence is there. The craft is there. The frame that tells the buyer, before they start evaluating the work, that the person who did this owned the mandate — that's the missing piece. A sequencing fix, a role-model clarification, and a causal-argument upgrade. The hardest part is already done.