Full Case Audit: CS-02 Thermo Fisher mySupply — Human-Agent Decision Architecture

Current-State Summary

Fetched July 19, 2026. The full case is live, returns HTTP 200, and renders behind a localStorage access gate that still serves content before the browser-side check executes. The trust-architecture contradiction flagged in the prior site audit remains unresolved.

What's changed since the prior CS-02 audit. The 42% overhead reduction metric, missing from the teaser, is present in the full case hero stats row. No iframe dependency here, so the teaser's iframe fragility is irrelevant. No <img> tags in the fetched HTML, meaning imagery is either CSS-rendered or absent. The broken OG image (still 404) and the over-revealed artifact grid remain teaser-only problems.

What's new. The full case has no og:title, no og:description, no og:image, no meta description. When a buyer shares this link in Slack or email, the preview renders as a bare URL.

The Central Finding

The case has the architecture of a human-agent coherence proof. It just doesn't know it yet.

Access scoping that encodes trust boundaries. Approval states that separate automated execution from human authorization. A batch QA gate where regulatory signature cannot be automated away. All present, all functioning as structural evidence. None framed for the buyer who needs to see them that way.

A Director+ buyer at Headway or Gusto who already thinks in terms of human-system decision boundaries will recognize the pattern without help. Everyone else will see a strong enterprise supply chain case and file it under "complex systems experience." The six audit points below are evidence for this finding. The fix is roughly 300 words of new copy. Not a rewrite. Framing.

Audit Point 1: 0→1 Mandate Under Pharma Regulatory Constraints

Verdict: Adequate on 0→1. Gap on regulatory.

The hero works. "The supply chain six partners never had" is a 0→1 headline. The supporting copy makes the before-state vivid: spreadsheets, phone calls, partners learning about batch problems at the delivery gate. The brief block confirms scope: one designer, two BCG DV engineers, twelve months, six partners, nine manufacturing sites across EU, North America, and Australia.

A buyer reading this understands Juno built something from nothing at enterprise scale. Good.

What's missing is the regulatory dimension. The hero says "world's largest pharma manufacturer" and the problem section references CDMO operations, but the constraints that make pharma supply chain design categorically harder than logistics SaaS never appear above the fold. GDP. cGMP. Batch release regulatory requirements. None of these are in the full case. The agentic section says "regulatory signature is irreplaceable," but the specific regulatory frameworks are absent. The teaser's artifact grid references GDP and cGMP. The full case itself does not.

Most enterprise designers' portfolios contain complex systems. Almost none contain systems built under pharma regulatory constraints. The regulatory dimension is a differentiator, and its total absence from the full case means the buyer who would value it most never encounters it.

Add one sentence in the hero or problem section. Something like: Pharma batch release operates under GDP and cGMP. Every design decision had to preserve the regulatory chain of custody while making the system usable for six different partner organizations. This tells the Headway buyer that Juno understands compliance-constrained design. It sets up the agentic section's human gate as a payoff rather than a surprise. And it connects directly to the human-agent lens: regulatory constraints are, structurally, constraints on where automation can and cannot replace human judgment. Name them early. The buyer reads the entire case through that frame from that point forward.

Audit Point 2: Research-to-Diagnosis Chain

Verdict: Strong structure. Adequate legibility.

The problem section states that 32 interviews traced the issue to no shared source of truth. The solution section opens with "Five modules. One shared reality" and explicitly says each research failure mode became a design brief. The five Problem→Module pairs are presented as a visible map.

The derivation is there. A careful reader follows it. But "32 interviews" appears once in the problem section, and the five failure modes emerge in the solution section without a transition that names the diagnostic step. How did 32 interviews become five failure modes and not seven? Or three?

This matters for the human-agent lens because the failure modes ARE the decision boundaries. They define where the system needs to act. If the reader doesn't understand how those boundaries were derived, the architecture that follows feels asserted rather than earned.

Add one bridging paragraph between the problem and solution sections. 32 warehouse interviews across nine sites surfaced dozens of complaints. Five were structural: problems that, if solved, would collapse the others. Each became a module brief. Fifteen seconds to read. Tells the buyer Juno doesn't just collect research. Juno diagnoses. And the diagnosis produces the decision architecture.

Audit Point 3: Failure-Mode-to-Module Traceability

Verdict: Strong.

Best-executed section of the case. Each module traces to a named problem with specific evidence:

• Problem 01 (197 orders, exceptions buried) → Module 01 Orders (exception-first default, "All" still holds the full list)
• Problem 02 (5–10 hours of status calls per batch) → Module 02 Batches (live kanban, At Risk flag surfaces early)
• Problem 03 (OTD measured differently, gaps invisible) → Module 03 Dashboard (internal and customer KPIs side by side)
• Problem 04 (forecasts as .xlsx email attachments) → Module 04 Forecasts (structured submission, version control, SAP auto-load)
• Problem 05 (capacity constraints discovered post-commitment) → Module 05 Capacity (18-month heatmap, constraints visible before commitments)

A buyer follows the logic from problem to solution without inference. The module notes add specificity: Late vs. Delayed definitions in Module 01, the 94% vs. 97% OTD gap in Module 03, the Approved/Under Review/Draft states in Module 04, true constraint vs. manageable over-capacity in Module 05.

No changes needed. This is diagnostic design thinking, and it reads.

What it doesn't do yet is name the decision boundary each module encodes. That's Audit Point 4.

Audit Point 4: Design Tradeoffs With Reasoning

Verdict: Gap.

The single biggest missed opportunity in the case.

The five modules contain several design-boundary decisions that are, functionally, tradeoffs about where the system should act and where humans must. Thermo Fisher sees all partners; partners see only themselves. Approved triggers SAP auto-load; Under Review and Draft do not. The exception-first default shows three action items, not 197. Grey cells in the capacity heatmap represent planned shutdowns made visible before partner commitments.

Every one of these is a decision about what to automate, what to gate behind human action, and what to scope by trust level. None are framed as tradeoffs. The case presents them as features of the solution, not as choices made against alternatives.

When you decided the Orders module defaults to Exceptions rather than All, you made a decision about where the system should filter and where the human should browse. When you decided that forecast approval triggers SAP auto-load but draft and review states do not, you drew a line between automated execution and human authorization. When you scoped partner visibility so each partner sees only their own data, you made a trust-boundary decision with regulatory implications.

Right now, these read as feature descriptions. They should read as design philosophy in action.

You don't need a separate tradeoff section. You need one or two sentences per module that name the alternative and the reason.

For Module 01: We considered showing all 197 orders with exception flags inline. Testing showed managers ignored flags in a full list. The default had to be the exception view, with the full list one click away for audit purposes.

For Module 04: We could have auto-loaded forecasts on submission. But pharma planning requires Thermo Fisher sign-off before data enters SAP. The approval gate isn't a workflow step. It's a regulatory boundary.

Each takes fifteen seconds to read. Each transforms a feature into a design decision about where human judgment is irreplaceable.

Audit Point 5: Partner Adoption as Design Outcome

Verdict: Gap.

The hero stats row says "6/6 pharma partners committed." The teaser uses "100% partner adoption." The full case has no adoption narrative.

Six independent pharmaceutical companies. Each with their own IT security review, their own compliance requirements, their own internal resistance to sharing operational data with a contract manufacturer. All agreed to use one system. That doesn't happen because the system exists. It happens because the design solved problems the partners actually had, in ways that respected their constraints.

The full case provides no evidence for how this happened. No partner objection. No adoption sequence. No moment where the design earned trust.

Add a short section after the five modules, before the agentic vision. Frame it around the question a buyer will ask: How did you get six pharma companies to actually use this?

You know the specifics. I know the structure:

If the visibility scoping in Module 03 was the trust mechanism that unlocked adoption, say so explicitly. If it was something else, name that instead. Partners adopted because the system respected the boundaries of what each organization should see and control. That's a design outcome. And it's the human-agent lens applied to organizational trust, not just to system architecture.

Audit Point 6: Agentic Vision — Placement, Prominence, and Connection

Verdict: Adequate placement. Gap in connection and enumeration.

The agentic section sits at the end, labeled as what Juno would build today, headed "Same problems. Different architecture." The framing is strong: mySupply was pull-based (someone had to open it), the redesigned architecture would be push-based (agents running continuously). The section explicitly states "One human gate stays" and names batch QA release as the place where "regulatory signature is irreplaceable."

The human-gate card is specific: MNZ-0441 Batch QA Release, five release criteria verified at 99% confidence, documents complete, user actions are Approve Release and View Batch Record. A buyer sees the concrete interface, not just the concept.

Two problems.

First, the enumeration. The section says the five modules become five agents. The live activity panel header shows "3 agents active" and names Exception Monitor, Document Compliance, and Forecast Deviation as automated actors. Human Gate and S&OP Review appear as cards but are presented as review states or regulatory checkpoints rather than named agents. This may be intentional. If Juno designed Human Gate and S&OP Review as human-mediated processes rather than autonomous agents, that actually strengthens the human-agent coherence argument: three agents run continuously, two processes remain human-governed. But the copy's claim of five agents and the visual evidence of three active creates ambiguity a buyer shouldn't have to resolve. Either name all five agents explicitly, or reframe to match what's shown: three agents, two human-governed processes, one irreplaceable gate.

Second, the connection. The agentic section doesn't connect back to the failure-mode derivation. It reads as a future-vision addendum rather than the logical conclusion of the architecture the case has been building. The five failure modes didn't just produce five modules. They produced five decision boundaries. The agentic vision is what happens when you push automation up to those boundaries and hold the line at the one place where human judgment cannot be replaced.

Add a bridging sentence at the top of the agentic section. The five failure modes defined where the system needed to act. The five modules defined how. The next design question was inevitable: which of these actions still require a human? Then the "one human gate stays" payoff lands as the answer to a question the entire case has been building toward.

What This Adds Up To

Here is what a regulated-platform buyer sees right now: a strong enterprise designer who built a complex supply chain system from zero and got six pharma companies to use it.

Here is what they could see with roughly 300 words of new copy: the person who designed the decision architecture between humans and systems in a pharma regulatory environment. Someone who derived decision boundaries from research. Encoded them as modules. Made explicit tradeoffs about where automation should run and where human judgment is irreplaceable. Earned adoption by respecting trust boundaries. Then articulated the agentic evolution of that same architecture.

The first reading is true but generic. Every strong enterprise designer has a complex system in their portfolio. The second matches the specific problem Headway, Gusto, Ramp, and every regulated-platform company is solving right now: where does the AI act, where does the human decide, and who designed that boundary?

There's a second buyer this case serves, and the evidence is already in the hero brief. One designer. Two engineers. Twelve months. Six partners, nine sites, three continents. For the enterprise buyer trying to stand up or elevate a design function, mySupply is proof of what a design team with diagnostic authority can deliver at a scope most organizations would staff with ten people and eighteen months. That's a design org transformation argument. It costs zero additional words. The team size and the outcome are already on the page. The connection between them just needs to be visible.

The structure is right. The derivation is visible. The human gate is named. You need a regulatory sentence in the hero, a bridging paragraph after research, tradeoff reasoning per module, a short adoption narrative, and a connecting sentence before the agentic section.

The case is 80% of the way to being the strongest regulated-platform proof in your portfolio. The remaining 20% is framing. And framing is what determines whether a buyer sees "strong designer" or "the designer who solves the problem I have right now."