Coordination contract

The primitive isn't a message. It's a commitment: a record of what the group agreed to, which every approval points at.

The schema is experimental. Field names and shapes will change before anything ships.

Example · experimental

{
  "objective": "Plan Japan trip",
  "participants": 5,
  "decision_rule": "unanimous",
  "proposal": {
    "destination": "Tokyo",
    "dates": "Mar 12–18",
    "price_per_person": 1280
  },
  "permissions": {
    "calendar": "availability only",
    "budget": "threshold only"
  },
  "approval": "5 / 5",
  "status": "committed"
}

Fields

objective: What the group is trying to do, in plain language.
participants: Who is in the mesh. In the full schema, a list of participant ids and their agents.
decision_rule: What counts as agreement: unanimous, a threshold, or an organizer's call with everyone's consent.
proposal: The exact outcome on the table. Approvals bind to this object.
permissions: Per category, what an agent may reveal: availability only, a budget threshold only, a ranking, and so on.
approval: How many participants have approved this version.
status: Where the mesh is: negotiating, proposed, committed, executing, completed, or closed.

Why approvals bind to a version

If an approval only said “yes to the trip,” a later change, such as a different hotel or $200 more, could ride on it. So an approval names one version of the proposal. Any change creates a new version, and the mesh has to ask again.

What a contract does not hold

Raw private data. The contract records the questions agents may answer and the answers they gave, never the calendar, budget, or inbox behind them.