Turn individual intent into complete groups.

Booking software starts after the hard part is over.

Court-booking tools assume four people already agree on what they want. They handle the transaction. They don’t handle what comes before it: finding the other three, and fitting a group’s schedules, locations and skill levels into one slot.

What has to be true before one game can happen:

• Four players, no more and no fewer.
• A time every one of them can make.
• A venue every one of them will travel to.
• Skill levels close enough for the game to be worth playing.
• A court that is actually free.
• No cancellation afterwards, or a replacement who fits.

Each condition is easy alone. Together they are a constraint problem over people who answer on their own schedules, in their own words.

People don’t fill in forms. They say what they can do.

{
  "activity": "padel",
  "preferred_areas": [
    "Gurgaon"
  ],
  "availability": [
    {
      "day": "saturday",
      "daypart": "evening",
      "earliest": null,
      "latest": null,
      "quote": "Saturday evening"
    }
  ],
  "skill_band": "beginner_intermediate",
  "party_size": 1,
  "social_flexibility": "open_to_new_people",
  "hard_constraints": [],
  "soft_preferences": [
    "Somewhere around Gurgaon rather than one exact venue"
  ],
  "ambiguities": [
    "\"Evening\" has no start or end time.",
    "\"Around Gurgaon\" does not say how far the player will travel."
  ]
}

Claude’s job is to turn the sentence into the object. Notice what the object keeps: the vague word “evening” is recorded as an ambiguity instead of being guessed into a time, and hard constraints are stored apart from soft preferences. How Claude is used.

One loop, two kinds of authority.

The full architecture, with failure modes, is on Technology. A deterministic worked example, with rejected proposals, is at the worked example.

We start with padel because the constraint is unusually clean.

Padel is played as doubles. A standard game needs four players, so someone always has to assemble the four. That makes coordination a requirement of the sport rather than a feature added on top. It also makes success easy to define and measure: a game either has four validated players on a free court, or it doesn’t.

Padel is the starting environment, not the boundary. The same shape (a fixed number of people, one place, one time) appears in other racquet sports, pickup sports, classes and small-group activities. Doubles does not operate in any of them today. More on the wedge.

Rules can enforce a constraint. They can’t read a sentence.

Real availability arrives like this:

• “Saturday evening, or Sunday morning if the same group is playing.” A conditional.
• “Can do 7-ish, but I have to leave by 8:30.” A soft start and a hard end.
• “Gurgaon is fine, I’d rather not cross the city.” A preference with no boundary.
• “Beginner, but I play tennis.” A skill level that needs interpretation.

A fixed form can’t hold these. A model can read them. But a model should not be the thing that decides whether a court is free, or whether payment has cleared. So the work is divided.

Where Claude sits, and where it doesn’t.

Claude reasons. Deterministic systems decide what is true.

A model may propose a group. It cannot override an unavailable court.

Why Claude, and what that boundary looks like in the code.

How we will know whether it works.

Coordination quality can be measured. These are the dimensions the evaluation is being designed around. They are definitions, not results; no scores have been produced.

• Hard-constraint violation rate
• Group completion rate
• Human clarification rate
• Cancellation recovery rate
• Manual intervention rate
• Matching stability
• Preference satisfaction
• Time to complete coordination
• Tool-call failure recovery

The research programme and evaluation design.

What exists, stated plainly.

Verified facts and their sources are listed on Evidence.

Where to read next.

• ProductWhat a player experiences, and what is built, manual or planned.
• TechnologyThe architecture: intent, reasoning, validation, tools, state, failure modes.
• ClaudeWhere Claude sits in the system, where it does not, and why.
• ResearchThe research question, evaluation design and failure taxonomy.
• EvidenceVerified facts, in-development work and research directions, separated.
• CompanyWho is building Doubles and where.