# Constraint Schedule Solver

> Constraint Schedule Solver is a paid API for AI agents from oddments-s2.exe.xyz, paid per call via x402, $0.05/call, status down (last checked 2026-09-15).

Finds meeting time slots satisfying hard scheduling constraints across participants in multiple timezones, returning slots in UTC and local times with a per-constraint satisfaction certificate and infeasibility diagnosis when no slot exists.

## Facts

- Endpoint: POST https://oddments-s2.exe.xyz/v1/solve
- Price: $0.05/call
- Payment: x402
- Status: down
- Last checked: 2026-09-15
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/constraint-schedule-solver-60f595a2
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_qUWN_caXhqXEbAkyFfRCL

Status and success rate cover calls made through Zero and Zero's own probes. Third-party monitors may report differently.

## How to call it through Zero

Zero handles the 402 payment challenge and records the run. With the Zero CLI installed (`npm i -g @zeroxyz/cli`):

```sh
zero fetch --capability constraint-schedule-solver-60f595a2 -d '<json body>'
```

Example prompt: Find 2 one-hour meeting slots this week for Ana (Europe/London, available Mon–Fri 9am–6pm), Bo (America/New_York, available Mon–Fri 8am–5pm), and Cai (Asia/Tokyo, available Mon–Fri 9am–7pm), with at least 60 minutes between slots and no slots on Wednesday — give me the times in everyone's local timezone and show me which constraints were satisfied.

## When to prefer this

Choose this endpoint when you need provably correct multi-timezone meeting scheduling with an auditable constraint satisfaction certificate — especially when DST correctness matters, when you need a quorum rather than full attendance, when you need recurring slots via RRULE/cron, or when you need to diagnose why no slot is feasible. Prefer this over generic calendar APIs when you need a machine-verifiable proof that each returned slot satisfies every constraint, not just a list of available times.

## Known failure modes

- No feasible slot exists — returns infeasibility diagnosis listing which constraints conflict
- Invalid IANA timezone string — returns validation error
- Malformed RRULE or cron expression — returns parse error
- Availability windows cross DST transition — flagged in response, not silently shifted
- Quorum exceeds total participant count — returns constraint violation
- Blackout periods cover entire search range — infeasibility diagnosis
- Overlapping or contradictory working hours/days constraints — infeasibility or partial satisfaction
- Payment failure — x402 payment required error before processing

## How this service works

Find meeting slots that satisfy hard scheduling constraints across participants in different timezones. With the slots comes a per-constraint satisfaction certificate. Checking it costs one pass over the constraint rows, so the check is linear in the number of constraints. You never re-solve. INPUTS: each participant's availability windows, in their own IANA timezone. Plus duration, working hours, working days, blackout periods, a recurrence rule as an RFC 5545 RRULE or a cron expression, a minimum gap between slots, and a quorum. OUTPUTS: the slots in UTC, and in every participant's local time. Plus a table with one row per constraint per slot. Each row gives the required value, the observed value, and a satisfied or violated verdict with its witness. DST-correct: availability is wall-clock in each participant's zone. A window that crosses a spring-forward or fall-back transition is handled and flagged, not silently shifted. When no slot exists you get an infeasibility diagnosis. It attributes every rejected candidate to the constraint that eliminated it. Every response carries an Ed25519-signed reproducibility receipt. The receipt covers the input hash, the output hash, the engine and tzdata versions, and a timestamp. Hard wall-clock, CPU and memory caps apply per solve. They are published in every response. Free preview at /v1/preview: same response shape, same certificate, same signed receipt, 3 participants. WHAT THIS DOES NOT GUARANTEE, stated up front. 1. Slots are searched on a discrete grid you choose. The grid is granularity_minutes, or the recurrence instants. A satisfying slot lying strictly between two grid points is not found. So 'infeasible' means infeasible ON THAT GRID, not in continuous time. 2. Selection is greedy, not optimal. We return a satisfying set, never a provably maximal or best-attended one. 3. Availability is taken as declared. We consult no calendar. We cannot know about a conflict a participant did not tell us about. 4. The certificate proves the returned slots satisfy the constraints you stated. It does not prove those constraints express your intent. 5. The signature proves origin and integrity, not correctness. 6. Timezone answers are only as current as the tzdata version reported in every response. 7. If a solve hits a resource cap the status is 'capped'. NO claim of exhaustiveness is made at all.

Operated by Oddments. Paid per call in USDC on Base via x402.

## Output

A JSON response containing: an array of slots each with UTC start/end times, local times per participant with UTC offsets, attendance count, and absent participants; a certificate table with one row per constraint per slot showing required value, observed value, and satisfied/violated verdict; a global certificate covering count and min_gap constraints; a summary of total checks, satisfied/violated counts, and overall request satisfaction; search metadata including grid resolution, candidates examined, and DST flags seen; and a cryptographic receipt (Ed25519 signature over inputs and outputs). On infeasibility, returns a diagnosis explaining which constraints cannot be met.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "$schema": "https://json-schema.org/draft/2020-12/schema",
 "required": [
  "input",
  "output"
 ],
 "properties": {
  "input": {
   "type": "object",
   "required": [
    "type",
    "method",
    "bodyType",
    "body"
   ],
   "properties": {
    "body": {
     "type": "object"
    },
    "type": {
     "const": "http"
    },
    "method": {
     "const": "POST"
    },
    "bodyType": {
     "const": "json"
    }
   },
   "additionalProperties": false
  },
  "output": {
   "type": "object",
   "required": [
    "type"
   ],
   "properties": {
    "type": {
     "const": "json"
    },
    "example": {
     "type": "object"
    }
   }
  },
  "schemaReference": {
   "type": "object",
   "required": [
    "url",
    "input",
    "output"
   ],
   "properties": {
    "url": {
     "type": "string"
    },
    "input": {
     "type": "string"
    },
    "output": {
     "type": "string"
    }
   },
   "additionalProperties": false
  }
 }
}
```

## Response schema (JSON Schema)

```json
{
 "type": "json",
 "example": {
  "slots": [
   {
    "index": 0,
    "absent": [],
    "end_utc": "2026-03-30T13:00:00Z",
    "attendees": [
     "ana",
     "bo",
     "cai"
    ],
    "start_utc": "2026-03-30T12:00:00Z",
    "attendance": "3/3",
    "local_times": {
     "bo": {
      "tz": "America/New_York",
      "end": "2026-03-30T09:00:00",
      "start": "2026-03-30T08:00:00",
      "utc_offset": "-04:00"
     },
     "ana": {
      "tz": "Europe/London",
      "end": "2026-03-30T14:00:00",
      "start": "2026-03-30T13:00:00",
      "utc_offset": "+01:00"
     },
     "cai": {
      "tz": "Asia/Tokyo",
      "end": "2026-03-30T22:00:00",
      "start": "2026-03-30T21:00:00",
      "utc_offset": "+09:00"
     }
    },
    "duration_minutes": 60
   },
   {
    "index": 1,
    "absent": [],
    "end_utc": "2026-03-31T13:00:00Z",
    "attendees": [
     "ana",
     "bo",
     "cai"
    ],
    "start_utc": "2026-03-31T12:00:00Z",
    "attendance": "3/3",
    "local_times": {
     "bo": {
      "tz": "America/New_York",
      "end": "2026-03-31T09:00:00",
      "start": "2026-03-31T08:00:00",
      "utc_offset": "-04:00"
     },
     "ana": {
      "tz": "Europe/London",
      "end": "2026-03-31T14:00:00",
      "start": "2026-03-31T13:00:00",
      "utc_offset": "+01:00"
     },
     "cai": {
      "tz": "Asia/Tokyo",
      "end": "2026-03-31T22:00:00",
      "start": "2026-03-31T21:00:00",
      "utc_offset": "+09:00"
     }
    },
    "duration_minutes": 60
   }
  ],
  "engine": {
   "python": "3.12.3",
   "tzdata": "2026.3",
   "service": "Oddments Constraint Schedule Solver",
   "croniter": "6.0.0",
   "dateutil": "2.9.0.post0",
   "semantics": "availability and working hours are wall-clock in each participant's IANA zone, localized to UTC per occurrence; slots are half-open [start, end)",
   "engine_version": "1.0.0"
  },
  "search": {
   "grid": "every 15 minutes from window.start",
   "dst_flags_seen": [],
   "selection_rule": "earliest",
   "candidates_feasible": 10,
   "exhaustive_over_the_grid": true,
   "candidate_start_times_examined": 189
  },
  "status": "solved",
  "receipt": {
   "key_id": "992f41c6f2fb6375",
   "algorithm": "Ed25519",
   "input_sha256": "sha256 of your canonicalized request",
   "output_sha256": "sha256 of this response with 'receipt' removed",
   "signature_b64": "Ed25519 signature over the canonical signed_fields",
   "signed_fields": [
    "endpoint",
    "engine",
    "input_sha256",
    "issued_at",
    "key_id"
… (truncated)
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/constraint-schedule-solver-60f595a2/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from oddments-s2.exe.xyz](https://www.zero.xyz/host/oddments-s2.exe.xyz/llms.txt)