Courses / Systems thinking and operations / Operate a system, not an isolated metric / Repair an operating system under constraints Build and defend your work Repair an operating system under constraints Model a service desk, workshop or small supply chain. Choose a bottleneck or shortage, compare two interventions, and stress-test the recommendation against timing, delayed delivery or shared failure. Use evidence from at least two experiment mechanisms; improved local utilization alone is not sufficient.
Choose an audience, investigate alternatives, copy evidence from your experiments, and produce an artifact. You can open this project at any time. Reports, numerical transfer checks and human review are separate outcomes.
Your project workspace Choose the kind of work you want to produce School investigation College investigation Workplace application Design a school-event queue and supply plan. Use token or browser experiments to compare staffing placement and replenishment; explain who waits and who receives scarce supplies under your proposed rule.
1. Collect and compare evidence Required experiment sources:
Include every source above and at least one pair with different inputs from the same experiment. Explain confounding changes yourself; the presence check does not judge your interpretation.
Open an experiment and change an input or capture a trial to make evidence available here.
2. Write and revise your report System boundary and service objective Draw or describe stages, stocks, delays and customers. State an overall service objective and one minimum service or reliability constraint.
Evidence for the limiting mechanism Use a trace to identify a bottleneck, timing mismatch, pending-order error or shared failure. Explain why a plausible local improvement would not solve it.
Policy comparison under equal conditions Compare captures under the same demand and resource budget. Report completed work, backlog or shortages, not just capacity or activity.
Who benefits and who waits Inspect per-period or per-branch outcomes. Describe an unintended consequence or fairness trade-off hidden by totals.
Stress test and implementation proposal Test delay, a demand surge, damaged stock or common outage. Recommend a policy with monitoring and rollback thresholds; separate synthetic findings from workplace evidence.
Your artifact: code, analysis, prototype or decision brief This field stores up to 12,000 characters of inert text. Code runs only through the explicit bounded editor in the relevant lessons; project attachments never execute.
Load a text artifact Review your work against the rubric The system boundary includes at least one relevant delay or buffer. Evidence identifies a limiting mechanism rather than equating busyness with success. Alternative policies use comparable resources and inputs. Distributional outcomes and common-cause risks are considered where relevant. The proposal includes an adverse scenario and empirical verification needs. 14 evidence requirements remain Capture evidence from queues and bursts. Capture evidence from find the bottleneck. Capture evidence from staffing to demand. Capture evidence from inventory and lead time. Capture evidence from delayed feedback orders. Capture evidence from reliability and common causes. Capture evidence from scarce supply allocation. Include two different input configurations from the same experiment to compare. Write your system boundary and service objective. Write your evidence for the limiting mechanism. Write your policy comparison under equal conditions. Write your who benefits and who waits. Write your stress test and implementation proposal. Add your project artifact: code, analysis, prototype or decision brief. Record my report Download report and evidence Editing the report or evidence returns it to draft. Recording verifies field presence and input comparisons, not correctness of your reasoning or code.
3. Check transfer to unfamiliar cases These authored cases use different numbers or conditions from the lesson practice. They are public local checks, not secure certification. Each case permits three submissions. Opening, first responses and attempt counts survive imports; no reset creates fresh evidence.
Case systems-project-queue Open case systems-project-queue Case systems-project-pipeline Open case systems-project-pipeline Case systems-project-reliability Open case systems-project-reliability
Return to the course · My Work and backups
