Mastercase: Meridian Bay Ferries

The Client and the Mess

Meridian Bay Ferries runs the kind of service that executives still describe as straightforward because the route map looks neat on a slide. Five terminals. Nine vessels. Forty-three weekday sailings. Commuters in the morning, school groups at ten, tourists all afternoon, luggage spikes whenever a cruise ship anchors offshore, and tide windows that refuse to negotiate with anyone’s quarterly targets. On paper, the operator’s punctuality promise is simple: board quickly, depart on time, land to a waiting shuttle. In practice, the promise breaks three times before the customer leaves the dock.

The first break sits in ticketing. The booking flow and the confirmation email say one thing about boarding cut-off times; gate staff and harbour operations live by another. The second break sits on the dock. Gate readers stamp passengers against scheduled departure, while ramp crews load against physical readiness and whatever the harbourmaster is doing with berth sequence that hour. The third break shows up onboard and after arrival. A ferry can leave “on time” in the reporting system, miss the safe tide slot, arrive late enough to strand island passengers after the last shuttle, and still look green in the dashboard until someone reconciles the journey by hand. That is failure demand dressed as punctuality.

The stakeholder map was crowded from day one. Crew unions needed assurance that any automation would respect the safety walk, roster rules, and fatigue boundaries. The council harbourmaster controlled berth changes and tidal windows. The regional tourist board owned a stream of public complaints and reputational pressure. A third-party maintenance contractor held defect and reset notifications that often surfaced too late for passenger communications. Inside Meridian Bay itself, operations, ticketing, dock supervisors, and the call-centre had each built local workarounds. Nobody owned the promise end to end.

I framed the brief narrowly enough to finish and honestly enough to matter. I was not redesigning fleet strategy, procurement, or harbour infrastructure. I was redesigning the punctuality promise across ticketing, dock operations, and onboard recovery communications. Success meant fewer false on-time signals, fewer stranded passengers after disruptions, and a clearer human owner whenever the system shifted from promise to recovery.

That is why this chapter works well as a mastercase. It demands every surface without letting any one surface pretend to be the whole practice.

Surface Plan: Which Tool Where

I kept the engagement in one workspace, then chose surfaces by situation. Four of them were human-facing: CLI, Claude Code plugin, BUZZ, and DSH Studio. The standalone MCP server acted as the automation seam. I did not split the project by host. Every surface opened the same meridian-bay project and resolved the same evidence ids.

That distinction mattered because Meridian Bay had already suffered from tool sprawl. Ticketing had its own truth. Dock control had its own truth. Maintenance had its own truth. I refused to create a fourth or fifth local spreadsheet truth just because a host made it convenient. The whole point of ASD is that surface variety does not require evidence fragmentation.

Discover: Evidence at Ferry Scale

I started where transport redesign usually gets dodged: the dock in bad weather, early enough to watch the promise fail before anyone has time to explain it away. The CLI handled the first hour because it was the only surface I trusted on a windy pier with gloves on. I created the project, opened it, and started dropping raw records straight into the register. Every evidence id was content-addressed over (source, kind, body). That meant the same passenger sentence from two different interviews stayed two different records, while re-importing the same timetable paragraph stayed idempotent.

export ASD_WORKSPACE="$HOME/.asd/projects"
PID=meridian-bay
asd project-create --name "Meridian Bay Ferries" --client "Meridian Bay Ferries" --sector regional-transport --service "ferry punctuality recovery" --phase discover
asd project-open --projectId "$PID"
asd evidence-add --projectId "$PID" --source passenger-int-04 --kind quote --body "The app said boarding closed at 07:10. The gate clicked shut at 07:04 and the crew on the ramp still had three cyclists waiting beside me."
asd evidence-add --projectId "$PID" --source gate-readers-2026-02 --kind telemetry --body "Harbour East 06:00-10:00: 18.6 percent of scan events occurred after scheduled departure because the ramp-open timestamp lagged the gate-close timestamp."
asd evidence-add --projectId "$PID" --source timetable-v47 --kind document --body "Winter timetable v47 lists a six-minute foot-passenger cutoff at Harbour East, while the booking confirmation email promises boarding until two minutes before departure."

By the end of Discover, the core register held twelve records I trusted enough to synthesize from. Five were verbatim quotes, three were telemetry extracts, and four were documents. I am showing the ids because the hash discipline matters here; the case falls apart if you cannot see how one quote becomes one stage, one defect row, or one blueprint step later.

Once the raw evidence was in the store, I moved into the Claude Code plugin for Discover synthesis. That switch was intentional. I wanted the role roster visible and the method canon close at hand. @researcher ran the contextual inquiry contract against the dock and passenger records. @librarian checked that the cut-off mismatch really belonged in evidence as a document conflict and not as my interpretation. The result was a research-plan artifact with id 1fb65eb4a19f9ac2cbb7d8e1231c3c91 and a stakeholder-map artifact with id 2b9b9a84e3111e95b04dcf8be21f3bd0. Both stayed draft until the Critic passed them. Both passed cleanly because the evidence was strong and the claims stayed humble.

The standalone MCP server also entered here, quietly. I used it for scripted corpus lookups against the public transport plugin case in Article 31 and the BUZZ boundary article in Article 37, plus a CI-side fact-check stub. That work never became evidence by itself. It gave me method discipline and bounded language. The ferry case still had to earn its own register.

Define: Synthesis Under Review

Define happened inside the Claude Code plugin because this was the phase where role handoffs helped more than a plain shell. I wanted a visible thread showing who did what: @researcher consolidating ferry-specific patterns, @synthesizer clustering tensions, @mapper drafting a current-state journey, and @critic checking every artifact before it could go final. This is where the platform’s ten-role shape earns its keep. The work stays legible.

@researcher Pull only Meridian Bay evidence ids and separate dock, ticketing, onboard, and recovery signals.
@synthesizer Cluster them into tensions. No causes without evidence.
@mapper Draft the current-state commuter and visitor journey. Mark gaps explicitly.
@critic Review every node and reject any stage whose cited evidence does not resolve.
@librarian Check method provenance and keep article-derived language out of the artifact bodies.

The current-state journey landed as artifact 36a1d93b6b6fffadaaa97ebeafd5591d. The insight set landed as 12c7b3ee619b0513c088ab997facd793. The opportunity matrix landed as 506c6f55332d6102f45638e45f812114. The Critic’s passes were useful because they forced a distinction I see teams blur constantly: lateness, uncertainty, and recovery are related, yet they are not the same defect. Meridian Bay’s biggest wound was not absolute delay. It was false certainty. The system repeatedly promised “on time” after the journey had already entered a recovery state.

That synthesis produced three framing moves. First, the punctuality promise had to be rewritten as a journey promise, not a departure promise. Second, berth control and maintenance comms had to be treated as service-shaping backstage actors, not external noise. Third, compensation could not be designed as a finance feature alone; it was a recovery mechanism entangled with manifest accuracy, gate logic, and harbour authority.

The human Define gate mattered more than the artifacts. I presented the current journey and the stakeholder tensions to Meridian Bay’s operations director, customer director, and a union safety delegate. They approved the problem framing under receipt mbf-gate-define-002: the engagement would redesign the punctuality and recovery promise without pretending to solve fleet capital constraints. That decision sounds modest. It saved the project. Ambition without a tractable frame is how service programs die politely.

Develop: Concepts, a Veto, a Remedy

Develop is where people get seduced by speed. Meridian Bay gave me an especially tempting trap: automate refunds whenever gate scans and arrival telemetry showed a broken promise. It looked efficient. Finance liked it. Marketing loved the story. Passengers would probably have liked the headline. The concept-set artifact, 87d6f25ebca1c64025f434df72fbcad5, originally included an auto-compensate on promise break concept alongside a tide-aware boarding promise and a dock controller console.

The Critic vetoed that concept, correctly. The problem was not sentiment. The problem was missing failure-path evidence. The concept assumed the scanner history could distinguish passenger-caused misses from operator-authorized gate reopens, berth holds, freight interruptions, paper concession reconciliations, and late manifest merges. My own evidence set did not support that claim. A fast team would have shipped it anyway and called the defects “edge cases.” The ASD loop does not let me get away with that.

[
  {
    "rowKind": "defect",
    "severity": "high",
    "rule": "failure-path-evidence",
    "message": "The automated-refund concept assumes gate scans distinguish missed boarding from operator-authorized reopen events and post-departure manifest reconciliation. The current evidence does not support that claim.",
    "fix": "Add dock-operator evidence for gate reopen scenarios and replace automatic payout with a manual override step in the Agent Decision lane.",
    "evidenceId": "45a1897278eea02652d9c069157c6c736dcd558408384439fc9a63a09a9fcae3"
  }
]

The veto persisted as review-veto-log artifact edaba7bc9072c412b2fe5e2b9ae9bd0e, row r1, linked back to the concept set by reviewOf. That row did exactly what I want a review row to do. It named the violated rule. It explained the risk in operational language. It proposed a concrete fix. It demoted the concept back to draft without deleting the work or hiding the argument. Meridian Bay’s team could see the refusal, read it, and answer it.

Remediation required more evidence, not louder rhetoric. I went back to the dock and added two new quote records: 08ce9338a6966bcb54ee3954313d2d733c0084500e25a465cee66e9e4ee05ea6 from the dock supervisor who sometimes reopens a gate on harbourmaster instruction, and 36c217132b4d2ac18b333a71068d08c871064918f2ef5c15e422978e07c04633 from the gate agent who still reconciles family bookings and paper concession tickets by hand after departure. Those two records changed the concept materially. I rewrote it from auto-compensate to compensation proposal with human override.

That rewrite also clarified the six-lane future blueprint. The sixth lane was not there to make a moral call. It was there to support bounded operational decisions: propose a revised ETA once berth change and tide evidence aligned, flag likely compensation candidates after manifest reconciliation, draft a shuttle hold recommendation, and route accessibility exceptions to a human owner without pretending the model could decide boarding eligibility. The automation moved from action to decision support wherever the service crossed fairness, safety, or public authority boundaries.

The remediated concept passed on second review. Better, the union stopped resisting the entire blueprint conversation. Once the safety walk stayed human, the critics inside the system became more willing to let the agent lane exist at all.

Deliver: Blueprint, Rehearsal Channel, Board Readout

Deliver is where cross-surface continuity stops being elegant theory and becomes project hygiene. The future-state service-blueprint artifact, 8a620aca21b3db982525afcfef649ea3, held the familiar five canonical lanes—Physical Evidence, Customer Actions, Frontstage Interactions, Backstage Operations, Support Processes—plus the sixth Agent Decision lane. I used service-blueprinting to shape the operational flow, then evidence-gated-blueprint to force the stronger gate before readout.

The sixth lane carried only decisions that could be justified with resolvable evidence and handed to named humans when risk rose. It never owned phase authority. It never overruled the harbourmaster. It never bypassed the dock supervisor on accessibility or safety. Its job was disciplined assistance.

The rehearsal itself moved into BUZZ. I created a private channel for the dock-ops exercise, materialized the runtime roster, verified membership by public key, then posted three scoped mentions: one to the orchestrator for sequence control, one to the researcher for unresolved evidence questions, and one to the critic for failure-mode scrutiny. That BUZZ slice is written here in observed style because that is how a real rehearsal thread feels to the team, but I am keeping the claim bounded. The channel showed coordination and Canvas navigation. The ASD workspace remained the only source of record.

CH=8d35f071-1af4-4dc2-a4bc-8f7c308c3f39
ORCH=9c2f8e65c7d94eab81d7bcf4dbf6fdb6c5ec6d5e4eeeb6d6488cf7dbe81ab122
RESEARCHER=244b0e3cd4c1d143d7ce0c9fb9fa1dd3cf7af9a46b95f7df8e5d2333d6c5771e
CRITIC=7f4a2fdab7d8c8b9df55e4fd3bc96be9d7f6b6be7dbab7ca45be4f5e10a9d0cc
buzz messages send --channel "$CH" --mention "$ORCH" --content "Run the dock-ops rehearsal against project meridian-bay. Keep every recommendation tied to persisted ids."
buzz messages send --channel "$CH" --mention "$RESEARCHER" --content "Check whether the compensation branch still lacks evidence for gate reopen scenarios."
buzz messages send --channel "$CH" --mention "$CRITIC" --content "Challenge the six-lane blueprint on failure-path evidence and owner visibility."
node scripts/buzz-canvas-index.mjs render \
  --project-dir ~/.asd/projects/meridian-bay \
  --channel sd/meridian-bay-rehearsal --fictional \
  --planned prototype-plan --planned test-report --planned recovery-playbook \
  --out ./canvas
buzz canvas set --channel "$CH" --content - < ./canvas/meridian-bay.md
buzz canvas get --channel "$CH" > retrieved-canvas.md
node scripts/buzz-canvas-index.mjs verify --canvas-dir ./canvas --project-dir ~/.asd/projects/meridian-bay --retrieved retrieved-canvas.md --fictional

The Canvas round trip mattered because it kept the BUZZ thread navigable without turning the channel into a second database. The generated index pointed back to the actual evidence register, the blueprint, the veto log, the prototype plan, and the pending rehearsal outputs. Planned rows used only registered kinds: prototype-plan, test-report, and recovery-playbook. No fake phase-gate-decision row. No improvised deck artifact. No hand-written summary pretending to be the store.

The board readout happened in DeepSeek Harness Studio. That was the right surface because executives needed to read the project, not to watch me operate it. Studio’s dashboard opened meridian-bay; the Evidence tab showed the full register with kind filters; the Review tab showed the blueprints, the clean passes, and the resolved veto log; the Reports tab gave me the executive-summary, artifact-dossier, and traceability-matrix in one place. Studio reads the same store the CLI and plugin write. I did not have to stage a separate board pack in some forgotten folder.

One awkward but healthy detail surfaced during the board readout: DSH’s direct capability projection does not expose a bespoke phase.gate.status row. Good. That forced the board to read the actual review board state, the fact-check, and the explicit approval receipts rather than relying on a decorative green badge. Governance stayed visible as evidence and human decision, exactly where it belongs.

The Traceability Thread

The final move was the traceability report. I exported it because Meridian Bay’s board had already lived through one consulting program where the answer to every challenge was “trust the synthesis.” That phrase should be retired. I wanted a reader to travel from a passenger quote to a journey stage, from a journey stage to a concept change, from that change to a blueprint step, and from the blueprint step to the final board pack without leaving the project.

PID=meridian-bay
asd export-report --projectId "$PID" --kind executive-summary
asd export-report --projectId "$PID" --kind artifact-dossier
asd export-report --projectId "$PID" --kind traceability-matrix
asd factcheck --projectId "$PID"
asd phase-advance --projectId "$PID" --toPhase deliver \
  --idempotencyKey meridian-bay-gate-develop-03 \
  --approvalReceipt '{"receiptId":"mbf-gate-003","approvedBy":"elise.nguyen","decision":"approve","rationale":"Blueprint, veto remediation, and rehearsal plan accepted for board readout.","approvedAt":"2026-08-23T15:20:00.000Z"}'

Those exports were useful because they made the case inspectable by people outside the design team. The executive-summary told the board what to decide. The artifact-dossier showed what existed and in what state. The traceability-matrix showed why the recommendation existed at all.

Notice what never changed across surfaces. The ids stayed the ids. BUZZ referenced them. Studio rendered them. The plugin wrote against them. The CLI advanced phase around them. The MCP lane replayed checks over them. That is the compounding value of a single evidence chain: the case becomes easier to challenge, easier to trust, and easier to resume.

The approval receipts told the same story. mbf-gate-001 moved the project from Discover to Define after the evidence scope and problem frame were accepted. mbf-gate-002 moved it into Develop after the current-state journey and tensions were signed off. mbf-gate-003 moved it into Deliver only after the veto had been remediated, the blueprint had passed, and the rehearsal plan existed. No phase moved because an agent felt confident. Every move carried a human name, rationale, timestamp, and idempotency key.

What Compounds

Meridian Bay Ferries is an illustrative composite. I need to say that plainly because the discipline of this book depends on honest boundaries. The BUZZ slice here is bounded. It shows the observed collaboration style, the Canvas index pattern, and the channel logic. It does not ask you to imagine that a message became persistence by magic. The DSH readout is equally bounded. Studio gives a board-grade reading surface over the same store. It does not replace the review gate, and it does not hide the human decision behind a UI flourish.

What does compound, though, is very real. The same project can survive field capture, agent synthesis, adversarial review, rehearsal coordination, executive scrutiny, and later reuse because the evidence thread never breaks. The first edition of service-design digitization gave teams prettier artifacts. This model gives them continuity. A dock supervisor can challenge a concept and see the exact quote that changed it. A union delegate can inspect the veto that stopped unsafe automation. A board member can ask why compensation stayed manual and get an answer that traverses evidence, review row, blueprint step, and receipt. That is a different level of organizational memory.

That is why I end the case here, at the point where most teams would start calling the work “implementation.” The mastercase has already shown the compounding move: one workspace, several surfaces, one evidence chain, one veto that improved the design, one set of human gates that stayed human. Everything after this—pilot tuning, KPI drift, new recovery patterns—can continue in the same project without reopening the trust problem. That is the whole bet of ASD. Methods run. Evidence stays put. People remain accountable.