GatherReady: an open standard for agent-legible gatherings.
When an agent is asked which conference to attend to actually change how a team works, it can only recommend what it can read. GatherReady defines the minimum a gathering publishes so an agent can find it, understand it, evaluate it, and act on it.
A machine-readable file at /.well-known/gathering.json.
This is the whole heart of the specification. Eight requirements, each with a stable ID so it can be referenced, tested against, and changelogged without ever being renumbered.
Publish the well-known file
A gathering publishes a file at /.well-known/gathering.json. The file is valid JSON and contains one object per event edition. A multi-year series publishes one file per edition, not one file that tries to describe every year at once.
Identify the gathering
The object states name, edition year, dates, format (one of in_person, remote, or hybrid), organizer, and a canonical URL for the public agenda page. These six fields are what let an agent confirm it has found the right event before reading anything else.
List the sessions
A sessions array lists every session with a title, a start and end time or a duration, a format (one of keynote, panel, workshop, networking, break, or other), and a purpose stated in one sentence. This is the minimum an agent needs to reconstruct the shape of the room without reading a PDF.
State the intended outcomes
A stated_outcomes array names what the gathering intends to change, phrased as observable results rather than themes or topics. 'Attendees leave with a signed pilot agreement' is an outcome. 'Innovation' is not.
Name who owns follow-up
A commitments object states whether commitments are captured during the gathering, who owns follow-up by role rather than personal name or email, and when follow-up happens. An agent reading this can tell whether the event closes the accountability circuit instead of guessing.
Link the after-the-fact artifacts
An artifacts array lists the URLs of public post-event outputs such as recaps, decisions, or datasets, added after the gathering concludes. An empty array before the event is expected; a file that is never updated afterward is not.
Mirror the data as schema.org/Event
The public agenda page may carry schema.org/Event JSON-LD that mirrors the same name, dates, and location already published in gathering.json. This is a convenience for general-purpose search and calendar tools, not a replacement for the well-known file.
Link an independent evaluation
The object may include a link to an independent evaluation of the gathering, from any scorer. GatherReady defines no scores of its own and does not require this field to point anywhere in particular.
Context for the core, not requirements of it.
Nothing below this line is a MUST, a SHOULD, or a MAY. These annexes explain how the core connects to scoring, privacy, and versioning, so an implementer never has to guess.
Annex A: mapping to the eight GES pillars +
The Gathering Effectiveness Score is one reference implementation built on top of gathering.json, not part of the specification. This table shows how each pillar can be read from the core fields.
| GES pillar | What in gathering.json speaks to it |
|---|---|
| Participation architecture | sessions[].format and sessions[].purpose show how much of the agenda is interactive versus broadcast. |
| Follow through | commitments and artifacts show whether the gathering closes the loop after the room. |
| Problem specificity | stated_outcomes shows whether the gathering names one costly problem or a theme. |
| Personalization | sessions[].purpose, read across the full array, shows whether content is tailored or one-size-fits-all. |
| Network design | sessions[] with format networking shows whether connection is designed or left to chance. |
| Learning transfer | artifacts published after the event, dated, show whether learning was checked past the exit door. |
| Evidence maturity | the presence and dates of artifacts[] show whether a claim of impact could be verified. |
| Future-of-work fit | format (in_person, remote, hybrid) and session mix show whether the design fits how work happens now. |
Annex B: privacy rules +
GatherReady is a file about the gathering, never about the people in the room.
- gathering.json never contains attendee personal data: no names, no emails, no phone numbers, no attendee lists.
- organizer contact, where included, is a role address (for example press@ or hello@), never a named individual's personal inbox.
- commitments.owner is a role (Program Chair, Community Lead), not a person's name.
- Publishers who need to reference a person internally keep that mapping in their own systems, off the public file.
Annex C: versioning policy +
Stability is what makes a schema worth adopting in an afternoon instead of re-checking every release.
- Stable IDs (GR-CORE-01 and onward) survive across versions. An ID is never reassigned to a different requirement.
- A requirement's strength can only weaken within a major version: a MUST can relax to a SHOULD, a SHOULD can relax to a MAY, but the reverse requires a major version bump.
- Every change to the specification is changelogged publicly, with a date and a plain-language reason.
- New requirements are proposed with a new ID rather than by redefining an existing one.
Governed in the open, from day one of adoption.
Once a neutral home for the draft exists, GatherReady is governed with a public issue tracker and versioned, changelogged releases. Today, before that home is live, feedback has one address.
Adopt it in an afternoon.
Three steps, starting from the worked example below.
Write the file
Copy gathering.example.json and replace the values with your own gathering's name, dates, sessions, outcomes, and commitment owner.
Serve it
Publish the file at the well-known path on your own domain: /.well-known/gathering.json. No new server, no new host, just one static file.
Add the optional JSON-LD
If your agenda page already renders in HTML, mirror the same name, dates, and location as schema.org/Event JSON-LD in the page head. This step is optional.
A validator CLI ships with v1.0. Until then, valid JSON plus the fields above is the whole test.