Skip to content
MARL in Cooperative Environments
Edit this page

Rubric

4 min read

The project rubric assigns equal weight to problem formulation, coordination and communication design, adaptation strategy, and evaluation quality. This page defines strong, adequate, and weak evidence for each criterion before showing how the four parts combine into one coherent system argument. Use it while designing, not only after writing: each mechanism should answer a stated problem, and each claimed benefit should appear in the evaluation plan.

CriterionWeight
Problem formulation25%
Coordination and communication design25%
Adaptation strategy25%
Evaluation and justification25%

Are agents, observations, actions, reward and objective clearly defined?

StrongThree to five roles with distinct observations. The state is visibly larger than any observation. At least one role holds information another needs. One shared reward, three or four terms, each justified. The objective sentence and the reward agree.
AdequateThe pieces are all present and some are vague. Observations are plausible but not clearly local. The reward is reasonable and unjustified.
WeakAn observation that is really the state. Per-agent rewards without acknowledging that this leaves the cooperative setting. Roles that differ in name only.

Coordination and communication design · 25%

Section titled “Coordination and communication design · 25%”

Do the chosen mechanisms actually address the stated problems?

The word doing the work is actually. This criterion is not testing whether you can name mechanisms.

StrongOne specific coordination problem, and a training approach chosen because it addresses that problem. Communication content justified against what the receiver needs. One constraint chosen and its consequences followed through. Rejected alternatives named.
AdequateSensible mechanisms, loosely connected to the difficulties. Communication specified without a clear account of what decision it changes.
WeakA list of techniques with no stated problem. Communication that transmits everything. A constraint mentioned and never used.

Does the system account for unfamiliar or changing agents, rather than assuming a fixed team?

StrongA specific unfamiliar condition. A training strategy with its cost acknowledged. An adaptation mechanism whose inputs are all local. A concrete behavioural consequence: what an agent does differently, and after what evidence.
AdequateDiversity or modelling proposed in general terms, with no stated consequence. Partner variation asserted rather than verified.
Weak“The system will adapt.” A partner model taking inputs no deployed agent has. No acknowledgement that the team might change.

The behavioural consequence is where this criterion is usually won or lost. “Maintains a partner representation” is a component; “reallocates from sector B to sector D after three steps of observing the new drone enter B” is a design.

Could the proposed experiments distinguish a robust cooperative system from one that merely performs well under familiar conditions?

StrongFour to six metrics across the categories. An evaluation matrix stating what each condition establishes. Held-out agents described behaviourally. One variable at a time. A falsification test, and a statement of what result would be worrying.
AdequateReasonable metrics, mostly measured under favourable conditions. Held-out agents mentioned without characterisation.
WeakTask performance only. A gap reported without both halves. Every test one the system is expected to pass.

Not whether your system would work. Nobody can tell that from two pages, and the project does not ask.

What is being assessed is whether you can take an open problem, formulate it as a cooperative multi-agent system, choose mechanisms that address the difficulties you identified rather than the ones you can name, plan for agents you did not build, and design experiments that could prove you wrong.

That is the Create level, and it is the last thing this resource asks of you.