Sylphx ComputeProduct site

First success

From a Binding to durable ids.

Install the generated SDK and CLI, create a Job, create a Schedule, and read the same identities back. It does not mint Binding, does not post to this site, and does not treat admission as a receipt. Live /v1 still requires a current Binding and Delegation on the API.

1. Install the generated SDK and CLI

Public clients are generated from this Product Contract. License is Proprietary; they are not Platform sylphx-sdk / sylphx-cli. CLI binary name is compute.

cargo install --git https://github.com/SylphxAI/compute --locked --bin compute

SDK dependency:

[dependencies]
compute-sdk = { git = "https://github.com/SylphxAI/compute" }

Tagged GitHub Releases attach the linux compute binary: https://github.com/SylphxAI/compute/releases. That artifact is produced from this repository; it is not a second protocol.

2. Use the API, not this site

Discover api_base from the Binding. The compiled default is https://api.compute.sylphx.com/v1.

export SYLPHX_PROJECT_BINDING='<sylphx-project-binding+jwt>'
export SYLPHX_DELEGATION='<short-lived-identity-delegation>'
BINDING="Sylphx-Project-Binding: $SYLPHX_PROJECT_BINDING"
AUTH="Authorization: Bearer $SYLPHX_DELEGATION"
BASE_URL="https://api.compute.sylphx.com/v1"

Do not post Jobs or Schedules to https://compute.sylphx.com. This host is the product site. Health probes live outside /v1 and are not first success. Compute does not mint Binding.

3. Create one revisioned Job

Every mutation has a caller-owned idempotency key. Same key, same digest: replay. Same key, different intent: conflict. The CLI sends Binding + Delegation and uses Binding api_base.

compute call CreateJob --body '{
  "idempotencyKey": "example-job-01",
  "name": "demo",
  "spec": {
    "application": {
      "digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "mediaType": "application/vnd.sylphx.compute.image",
      "sizeBytes": "1",
      "productId": "data",
      "retentionPolicyId": "retain-default"
    }
  }
}'

Keep job.identity.resourceId and revision. The response is a definition plus a mutation Operation, not execution.

4. Create one Schedule

Schedule is its own resource. Timezone is a field. Target is http or execute.

compute call CreateSchedule --body '{
  "idempotencyKey": "example-schedule-01",
  "spec": {
    "calendar": {"kind": "cron", "expression": "0 3 * * *", "timezone": "UTC"},
    "overlap": "skip",
    "catchUp": "skip",
    "target": {"kind": "http", "method": "POST", "url": "https://example.com/hook", "signed": true},
    "retry": {"maxAttempts": 3},
    "pause": false
  }
}'

Exact replay returns the same Schedule and Operation. A due Tick later is Clock fire through Journal Wake, not this command.

5. Read the same durable ids

First success is exact readback through the same Binding:

compute call GetJob --body '{"jobId":"<job-id>"}'
compute call GetSchedule --body '{"scheduleId":"<schedule-id>"}'

:execute admits an Operation. Until a Platform Work provider accepts a receipt for that generation, the truthful state may be blocked with no receipt and no usage facts. Do not invent success.

Local COMPUTE_API_KEY is scaffold for this repository, not production admission and not a second protocol. Generated SDK (compute-sdk) and CLI (compute) use this Product Contract with Binding + Delegation and Binding api_base. They are not Platform sylphx-sdk / sylphx-cli.