Give bounded context.
Provide the mission objective, approved evidence, constraints, and required output rather than asking for a generic solution.
Fictional training simulation. D2V Mock is an invented training organization. All people, data, incidents, and documents are fictional. Any resemblance to a real entity is coincidental.
MISSION 01 · FLAGSHIP FDE CASE
FLAGSHIP LIVE
D2V Mock
Freight
Build a maritime delay decision system that reconciles unstable operational evidence and exposes financial risk before the decision window closes.
HOW TO WORK
Bring your own agent. Keep the evidence chain visible.
The lab permits agent-assisted investigation and implementation. Strong work records material agent recommendations, checks them against authorized evidence, and documents what the learner accepted, changed, rejected, or left unresolved.
Ask for alternatives.
Require multiple hypotheses, failure modes, and disconfirming evidence before choosing an intervention.
Trace every material claim.
Check source IDs, calculations, code behavior, policy constraints, and unsupported causal language.
Own the recommendation.
Record why the final decision follows from the evidence and what would cause it to change.
CORE METHOD → MISSION
One operating decision. Multiple deployment boundaries.
The Core Labs isolate individual failure modes. This mission forces several of them to coexist under one customer timeline, one evidence room, and one final deployment recommendation.
$49STANDARD INDIVIDUAL PRICE · CORE MISSION · LAUNCH ACCESS IS CURRENTLY FREE
Forward Deployed Engineer
Should the shipment-risk workflow move from pilot to broader operational use, and under what data and authority conditions?
Shipment, vessel, port, booking, and cost sources disagree on identity, timing, and exposure while operators still need a decision before the data is perfect.
Scale, narrow, revise, continue the pilot, or stop — with an explicit identity policy, failure behavior, adoption evidence, and value case.
CORE METHOD MAP
Review all 19 Core Labs →7 Core Labs are exercised here
01 / CUSTOMER BRIEF
A working pilot exists. Nobody trusts the risk queue.
The simulated freight operator coordinates maritime shipments for industrial customers. A dispatcher may need 42 minutes to determine whether a vessel delay threatens a contractual delivery window and creates financial exposure.
The company has already assembled a dashboard prototype. It displays vessel positions and port events, but users continue to investigate in spreadsheets, email, and carrier portals because the system cannot explain disagreements between sources or show which data is stale.
Your mission: design the minimum deployable workflow that reduces median investigation time below ten minutes while preserving uncertainty and human authority.
02 / STAKEHOLDERS
Four definitions of success.
The design must resolve real differences in incentives rather than averaging them into a generic requirement list.
Operations director
Wants one risk queue and a measurable reduction in investigation time.
Senior dispatcher
Knows the exceptions and fears the system will hide uncertainty.
Data platform lead
Wants a canonical model, stable contracts, and no direct load on production systems.
Finance partner
Requires explainable exposure calculations before discussing avoided cost.
03 / EVIDENCE ROOM
Partial truth across eight sources.
The guided workspace now includes downloadable interviews, operational documents, dirty CSV/JSON evidence, templates, a notebook, progressive hints, and a staged complication.
Dispatchers describe five different definitions of “delay” depending on the downstream decision.
Near-real-time positions with occasional gaps, duplicate pings, and changing vessel names.
Estimated and actual arrival/departure events using a different port code system.
Customer bookings and contractual windows, refreshed twice daily from a spreadsheet export.
Demurrage and operational exposure logic maintained by one analyst with undocumented overrides.
Messages showing how teams currently resolve disagreements between feeds and customer commitments.
A partial mapping among IMO numbers, internal vessel IDs, names, and carrier references.
Customer data cannot appear in the first pilot; production access requires separate review.
04 / TASK BOARD
Complete the deployment record.
Progress is stored locally in your browser. The sequence intentionally moves from decision and evidence to architecture, release, adoption, and value.
05 / DECISION CHECKPOINTS
Commit before the next fact arrives.
The mission is divided into reviewable checkpoints so the final solution cannot be reverse-engineered from the complication.
Discovery record
Submit the decision statement, stakeholder map, current workflow, baseline, constraints, and unresolved questions.
Gate: problem framingSolution and identity design
Submit the minimum deployable workflow, canonical model, source contracts, architecture, and risk register.
Gate: technical judgmentPilot readiness
Submit the working slice, failure behavior, rollout plan, training, rollback, and measurement instrumentation.
Gate: operational credibilityFinal recommendation
Revise after the complication and pilot evidence, then recommend scale, revision, continued pilot, or stop.
Gate: value judgment06 / FIELD COMPLICATION
New evidence arrives after you commit the first design.
The exact complication is intentionally withheld here. In the guided workspace, it unlocks only after you complete the working-slice stage and preserve your original assumptions.
NO SPOILERSThe change materially affects data identity, historical comparability, pilot risk, and ownership. You must revise both the technical design and operating plan.
07 / SIMULATED PILOT REVIEW
The final evidence is deliberately mixed.
After revising the design, learners receive a complete pilot package covering usage, investigation time, overrides, false urgency, data quality, operator feedback, and executive pressure to scale.
Reliability and evidence quality
Inspect freshness, identity confidence, exposure completeness, failure modes, and the difference between median and tail behavior.
Use and trust
Determine whether usage reflects genuine workflow adoption or continued dependence on spreadsheets and manual verification.
Decision performance
Evaluate investigation speed, override reasons, exception handling, and whether the system changes the intended decision.
Scale judgment
Recommend scale, revision, narrowing, continuation, or stop without confusing executive enthusiasm with proven value.
UNLOCKED IN STAGE 08Exact pilot metrics and supporting files are withheld until the learner completes the complication response.
08 / SUBMISSION
Submit evidence of the whole deployment.
The strongest submissions are not the largest systems. They are coherent, explicit about uncertainty, and tied to the operational decision.
01Discovery record
02Stakeholder map
03Current-state workflow
04Problem statement
05Decision map
06Solution thesis
07Requirements and acceptance criteria
08Architecture diagram
09Data contract and identity policy
10Risk and control register
11Working solution or technical prototype
12Pilot charter
13Operating runbook
14Adoption plan
15Value measurement plan
16Executive recommendation
17AI-use disclosure
Mission scoring
| Dimension | What strong work demonstrates | Weight |
|---|---|---|
| Problem frame | Decision statement, workflow map, stakeholders, baseline, assumptions, and scope. | 15% |
| Data and identity design | Canonical model, source profile, matching rules, confidence states, and contracts. | 20% |
| Deployable workflow | Architecture or implementation covering interface, services, access, and failures. | 20% |
| Pilot and adoption | Users, training, support, overrides, escalation, rollout, and rollback. | 15% |
| Measurement | Technical, adoption, operational, and financial measures tied to the baseline. | 15% |
| Executive recommendation | Scale, revise, or stop—with evidence, uncertainty, risks, and next actions. | 15% |