Full Case Audit: CS-02 Thermo Fisher mySupply — Regulated-Platform Buyer Lens

Gating Status

The case URL returns HTTP 200 with the full 214,343-byte HTML document before any access logic runs. The password gate is client-side only. A script checks localStorage and redirects if the flag is absent, but the complete case content sits in the delivered HTML below that script. Bots, caches, view-source, and raw fetches all bypass the visual redirect.

The same vulnerability pattern visible in the "What Do You Count" essay exists here. Full content delivered to any requester regardless of the overlay experience.

In most portfolio cases a client-side gate is technical hygiene, but this case is about regulated access architecture, and the unprotected gate undermines the credibility of the work it presents. You are presenting a regulated operations platform built around partner-specific access permissions, audit trails, and human-gated approvals. The case itself relies on a gate that any hiring manager with dev tools can see through. A Gusto payroll-compliance reviewer or a Headway insurance-workflow evaluator will register the gap between the judgment you demonstrate inside the case and the judgment the case's own access architecture demonstrates.

1. 0→1 Mandate Framing

What the page shows. The hero states the platform went from zero to live in twelve months across six partners and nine manufacturing sites. The problem section names no prior product surface. The prior state is spreadsheets, phone calls, email chains, siloed SAP/LIMS/MES data. A reader can infer 0→1.

What the buyer needs. The buyer should not have to infer it. A Gusto or Headway panel evaluating Director+ candidates is specifically testing whether you can create from nothing under real constraints. They have seen plenty of candidates who optimized existing products. The 0→1 evidence is in the case. The mandate framing is buried.

Do this. Add one sentence near the hero or at the top of the problem section that makes the mandate explicit: you were brought in to design a new shared operating layer for a regulated CDMO environment where no digital product existed. Name the regulatory constraint as a shaping force on the design. Right now it reads as background context. Something close to: The design had to give partners real-time visibility without exposing unactionable internal data or breaking compliance boundaries.

That sentence does more work for a regulated-platform buyer than the $20M metric.

The pharma regulatory constraint is present throughout the case. Batch release, QA approval, audit trails, planned shutdowns, partner-visible performance boundaries, the human gate in the agentic section. But it is distributed across modules and never named early as the design mandate. Consolidate it. A Gusto hiring manager scanning this case in twelve minutes needs to see "regulated 0→1" in the first thirty seconds, not piece it together across five module walkthroughs.

2. Research-to-Diagnosis Derivation

What the page shows. 32 interviews identified a missing shared source of truth as the root cause. Five diagnostic signals follow (short-notice orders, status chasing, no shared KPIs, OTD spread by site, data outside PRISM). Each failure mode became a design brief.

The chain exists. The connective tissue is thin.

What's missing. Who were the 32 interviewees? What roles, which side of the partnership? How did you distinguish symptoms from root causes? The five failure modes feel like they arrived fully formed. A Director+ review at either company tests whether a leader can decide what evidence matters and turn ambiguous research into product architecture. The decision trail from "we heard X from these people" to "we concluded Y, which became five design briefs" is the proof of that capability.

Do this. Add a concise research-method bridge before the five failure modes. Two to three sentences. Name the interview populations (site managers, partner procurement leads, QA teams, whoever they were). State the analytical move that turned interview data into five discrete failure modes. Skip generic process language. No double-diamond diagram. What's useful here is the judgment call: what made you decide these five problems were the right five, and what did you leave out?

3. Module-to-Failure-Mode Mapping

What the page shows. This is the strongest structural element in the case. The mapping table pairs five problems with five modules before the detailed walkthroughs begin. Each module's body copy restates the failure mode before showing the interface mechanism. The embedded UI notes reinforce the mapping with specific design semantics: exception tabs, lifecycle kanban, partner-specific dashboards, forecast status badges, constraint heatmap logic.

A regulated-platform buyer reading this will see a designer who can translate research into architecture. Right signal.

One inconsistency to fix. Module 01's body copy says managers only needed to act on three exceptions. The UI mockup shows four exception rows requiring action. Small number. Big problem for this audience. A hiring panel evaluating someone for a compliance-adjacent platform role will treat a data inconsistency inside an auditability case as signal about operational attention. Reconciling this takes five minutes. Leaving it in can undermine your auditability argument in five seconds if a compliance-minded reviewer catches it. Fix before you share. [Confidence: high — the discrepancy is visible in the current HTML.]

Do this. Add a "failure → design mechanism → what changes for the partner" sentence in each module walkthrough. The mapping is strong but still asks the reader to infer how each interface choice changes partner behavior. Make the behavioral consequence explicit.

Here is what that sentence looks like for Module 02:

That is the model. Each module should have one sentence at this level of specificity:

• Module 04: Approval triggers SAP auto-load, which means the partner's forecast is live in the production system within minutes of sign-off instead of waiting for a 30-minute manual entry that might not happen until the next business day.
• Module 05: The 18-month heatmap means the partner sees a capacity constraint before committing orders to a month that cannot absorb them.

Same structure. Failure, mechanism, behavioral shift.

4. Tradeoff Reasoning

What the page shows. Tradeoff reasoning is present but implied. You chose to default managers to exceptions instead of all orders. You chose to show partners only actionable visibility rather than raw internal data. You preserved partner-specific dashboard access boundaries. You distinguished true constraints from manageable over-capacity. You retained a human gate for QA release. Each of these was a judgment call with a rejected alternative. None of them name the alternative or explain why it was rejected.

[Confidence: medium-high. This is my evaluative read of where the case is thinnest relative to what a regulated-platform buyer specifically evaluates. The page shows the decisions but leaves the reasoning implicit. A buyer less attuned to tradeoff reasoning might not flag this gap.]

The strongest explicit tradeoff appears in the agentic section, where automation handles routing and detection but QA release stays human because the regulatory signature is irreplaceable. That single decision, stated clearly, does more to demonstrate regulated-platform judgment than any of the outcome metrics. But it appears only at the end, and it should be doing work in the module walkthroughs too. More on this in Section 6.

Do this. Add short decision notes at two or three high-stakes points. Prioritize:

• Partner-visible status semantics. Why "delayed" (recoverable) versus "late" (commit date missed)? What was the alternative? What would happen if partners saw raw internal status codes?
• SAP auto-load on approval. You automated a 30-minute manual process. What approval gate did you preserve, and why was that gate the right boundary between automation and human judgment?
• QA release as human gate. Already partially stated in the agentic section. Pull it forward into the module walkthrough so it reads as a design principle established during the build, not a constraint discovered during the future-vision exercise.

Here is where the Gusto and Headway distinction matters. A Gusto payroll team lives in automation-versus-auditability tradeoffs daily. They will weight the SAP auto-load decision and the QA release gate heavily because those are structural analogs to their own compliance architecture. A Headway provider-network team will weight the partner-visible status semantics and the dashboard access boundaries more, because their core problem is multi-party trust across providers, payers, and patients. If Gusto comes first, lead with the automation gates. If Headway comes first, lead with the partner-visibility decisions. The evidence supports both. The emphasis should shift.

5. Partner Adoption as Design Outcome

What the page shows. The hero says 6/6 pharma partners committed. The module copy frames the system as fitted to partner workflows.

[Confidence: medium. My assessment that 6/6 currently reads as a business-case metric is an inference about how a buyer will interpret the framing, not a factual observation about what the page says. The page does not explicitly attribute adoption to design decisions or to commercial leverage. A buyer could read it either way. The risk is that without attribution, the default read at Director+ level is "BD got the partners to sign, design happened to be nearby."]

A hiring panel cannot tell from the current framing whether partners committed because the system was well-fitted to their workflows, because Thermo Fisher's commercial relationship required it, or because BCG's business case was persuasive. If adoption was a design outcome, the case needs to show which design decisions made adoption low-friction.

Do this. Turn 6/6 from a commitment metric into adoption evidence. State when partners committed: before launch, after pilot, after seeing specific workflow improvements? Name which design decisions reduced adoption friction. Connect partner adoption to trust under operational consequence.

For Gusto or Headway, the reusable proof point is that you designed a system where the partner's experience of using it was better than their experience of not using it, and that made adoption attributable to design quality. A regulated-platform buyer is listening for exactly that evidence.

6. Agentic Vision

What the page shows. The agentic section appears at the end as "03 If I were building this today." It reframes the five modules as five continuously running agents. It preserves the human gate for batch QA release. The examples are grounded in earlier case evidence: exception routing, document gaps, forecast drift, release gates, QA certificate gaps. The live activity log mockup for Monza shows three active agents scanning 195 orders, one human gate, and timestamped agent actions.

This section is well-built. It connects back to the case mechanics and avoids floating as a speculative appendix. Two issues remain, and sequencing is the more visible one.

The section's strongest buyer-facing evidence is the human gate principle: the explicit decision that automation handles detection and routing while regulatory signature stays human. That principle currently does double duty. It appears here as a forward-vision constraint and in Section 4's tradeoff territory as an implied design decision from the original build. Neither location gets the full weight. Consolidate. Establish the human gate as a design principle in the Module 02 or Module 04 walkthrough, where it was an active decision during the build. Then let the agentic section show how that same principle scales: what was a single approval gate in 2021 becomes the architectural boundary between agent autonomy and human authority in the agentic layer.

That arc from build-time tradeoff to future-vision principle is the strongest signal you can send to a regulated-platform buyer evaluating agentic AI capability. It demonstrates that you designed the human-machine boundary first and let automation fill the space around it.

Do this. Preview the agentic lens earlier. After the problem diagnosis or the module map, add one sentence: the original system was designed around exception visibility and structured gates, and that same architecture now points naturally toward agentic monitoring with human-gated decisions. This gives the final section the structural weight of a payoff.

Keep the final section as is. Add one forward link from the module map so the vision reads as derived.

Priority Stack

You have the long weekend before post-July 4th conversations resume. Here is the order.

• 1. Fix the access gate. Server-side. Non-negotiable. Everything else is positioning refinement. This is a trust defect.
• 2. Reconcile the exception count (three in copy, four in mockup). Five minutes to fix. The cost if missed is disproportionate to the effort.
• 3. Add the 0→1 regulated mandate sentence near the hero. One sentence that reframes the entire case for the buyer you're targeting.
• 4. Add two tradeoff decision notes in the module walkthroughs. Partner-visible status semantics and QA release gating are the highest-value candidates. Modulate emphasis based on whether Gusto or Headway comes first.
• 5. Add the research-method bridge. Who you interviewed, what analytical move produced five failure modes.
• 6. Reframe 6/6 as design-outcome evidence. When and why partners adopted.
• 7. Preview the agentic lens earlier in the narrative sequence and consolidate the human gate principle across sections.

Items 1 and 2 are blockers. Items 3 through 7 are positioning improvements that compound. If you can only do three things before Tuesday, do 1, 2, and 3.

The case itself is structurally strong. The failure-to-module mapping is the clearest architectural evidence I've seen in a portfolio case for this buyer type. The agentic section is grounded where it could easily have been speculative. The evidence is all here. The case asks the reader to do too much inference at the exact points where a regulated-platform buyer needs explicit judgment. Close those gaps and this case does what it needs to do.