Running it locally is not a deployment
Starting the door on your machine exercises the same code path a platform runtime would, and claims nothing about a hosted state.
Operations · the service door
The door, the self-check, and the wake it refuses.
The service door is the runtime surface the platform wakes: one health document, one wake route, and a named refusal for everything else. This page is what an operator needs to run it, read it, and know what it will not do.
live:falsesimulation-onlynothing deployedwake fails closed
Before anything else
Nothing is deployed today.
The door is source in this product and it runs locally. No hosted service is released, no image is admitted to the platform, no hostname is published, and the declared schedule row is paused.
The effect path is simulation-only
The door performs no decision of its own. The self-check runs a simulation-only vertical, and no adapter in the product can reach an external effect.
The schedule cannot fire
The declared cycle is paused, so no wake arrives on its own. The wake route refuses everything it is given.
Running the door
What serve binds, and what it reads.
The serve mode takes no arguments. It resolves its facts from the environment, binds the platform’s port, runs the boot self-check, and then answers two routes.
# The door on a port of your own, over a local history file
PORT=8080 KALKAS_HISTORY_SOURCE=history.jsonl \
cargo run --bin kalkas -- serveWhat it binds
- Every interface, on the resolved port: the platform probes it internally, and the port is never published as a public address.
- The port is the platform-injected one; the manifest declares 8080 as the value used when none is injected.
- It is the foreground process of the image, so the runtime ends when the door ends.
| Key | What it changes |
|---|---|
| PORT | The port the door binds on every interface. The platform injects it; when it is absent the door uses the port the manifest declares, 8080. A port it cannot bind stops the door rather than listening somewhere undeclared. |
| SYLPHX_GIT_COMMIT_SHA | The revision the door reports. A runtime value wins over the image’s own default, and a runtime with no value reports unknown. |
| KALKAS_HISTORY_SOURCE | The history file the boot self-check reads. The image ships its own asset and verifies it at build time; this key points the check at another file, which is how a local run uses your own slice. |
| SYLPHX_URL | The platform connection credential. The door reports only whether it is configured, as a boolean, and never its value or contents. |
Boot self-check
What the runtime proves before it answers.
The self-check runs before the socket binds, so a probe can never observe a half-known state. It is the same sourced vertical an operator runs by hand, executed once against the shipped slice.
- 01It reads the history asset, which the image decompressed and verified at build time and which the check verifies against the declared digest again before a row is mapped.
- 02It seals the bounded slice into a point-in-time corpus, so every row carries its observation and availability times.
- 03It trains the candidate in-window and holds the later window out, then decides or abstains on the sampled cases under the mandate.
- 04It settles every sampled case, so the summary counts receipts this process actually produced.
- 05It prints the receipt document to standard output as one line and keeps a compact summary in memory.
ProofWhat a passing self-check proves
That this process read the exact history asset it was configured with, mapped it under the declared slice law, ran the decision loop over a held-out window, and produced the receipts in the summary. It does not prove a decision is correct, and it is not a performance claim.
FailureWhat a failing self-check serves
A named failure instead of a receipt: a missing history source, a rejected self-check law, or a rejected sourced run. The health document answers 503 with that name, and the door never fabricates a receipt it did not produce.
GET /healthz
The health document, field by field.
Health reports whether the process answers and what its self-check produced. It never reports a decision, and it never prints a secret value or a credential’s contents.
| Field | What it reports |
|---|---|
| service | The service this door belongs to. |
| revision | The image or checkout identity the door resolved from the environment. |
| live | false, in every answer. It is a posture statement, not a placeholder. |
| status | ok, or self_check_failed when the boot self-check did not pass. |
| boot_self_check | The summary of the run performed at startup, or the named failure instead. |
| env | Boolean environment probes plus the port the door resolved. |
| wakes_refused | How many wakes this process has refused. |
| boot_self_check | What it reports |
|---|---|
| boot_self_check.status | passed, or failed with the failure named instead of a receipt. |
| boot_self_check.source | The history file the self-check read. |
| boot_self_check.failure | Present only when the self-check failed: the name of the check that refused, so a failing door is diagnosable without reading the log. |
| boot_self_check.source_sha256 | The declared digest of the whole source artifact, verified before a single row is mapped. |
| boot_self_check.kept_rows | Admissible rows the declared slice kept. |
| boot_self_check.decision_cases | Sampled out-of-sample cases the run decided. |
| boot_self_check.acts | Cases whose decision was an act. |
| boot_self_check.abstentions | Cases whose decision was an explicit abstention. |
| boot_self_check.settlement_learning_receipts | Cases that settled and learned against their decision. |
| boot_self_check.run_digest | The aggregate identity of the receipts this process produced. |
StatusTwo answers, both honest
200 with status ok when the self-check passed. 503 with status self_check_failed and the failure named when it did not. There is no third, reassuring state.
LimitWhat health is not
A passing health document is not a verified outcome, not a decision, and not a release. The console's service health view shows the same contract next to a live readback when a door is running for you.
The Compute wake
The wake runs nothing, and says why.
The cycle’s only trigger is a wake posted by the platform’s Compute schedule. Until the door can verify a signed tick, every wake is refused by name and counted rather than silently dropped.
# The health document, as the platform probe reads it
curl -s http://127.0.0.1:8080/healthz
# The wake, refused: no bearer tick, then any token at all
curl -si -X POST http://127.0.0.1:8080/internal/compute/cycle
curl -si -X POST http://127.0.0.1:8080/internal/compute/cycle \
-H 'authorization: Bearer <any token>'RefusedTwo refusals, one behaviour
- No usable bearer tick: 401 compute_tick_bearer_required.
- Any token presented: 501 tick_verification_unimplemented, because the verification exists in the contract but not yet in the door.
ContractWhat the tick will have to be
A token issued by Compute for this door: signed with the algorithm the contract names, verified against the key set Compute publishes, carrying the token type the contract names, and naming this door’s exact address as its audience. A bad, absent, or unverifiable tick keeps failing closed and prints no metric.
Both refusals run nothing and both increment wakes_refused, so the refusal is visible in the health document instead of disappearing. What the door does with a verified wake — consume the authorities’ receipts, gate the candidate, and decide — is the serverless cycle entrypoint, documented in the command reference.
Everything else
Every other answer is a named refusal.
The door reads one request per connection with a bounded head and body, and answers everything outside its two routes with a JSON error a caller can act on.
| Status | Error | When |
|---|---|---|
| 400 | malformed_request | The request head is not a well-formed HTTP/1.0 or HTTP/1.1 request. |
| 401 | compute_tick_bearer_required | The wake presented no usable bearer tick. It runs nothing and is counted. |
| 404 | route_not_found | The path is not one of the two routes this door serves. |
| 405 | method_not_admitted | A known route was reached with the wrong method. The answer carries the method the route admits. |
| 411 | length_required | The body was framed with chunked transfer encoding or left undeclared. This door admits a bounded declared length only. |
| 413 | payload_too_large | The declared body exceeds the size this door admits. |
| 501 | tick_verification_unimplemented | Any token was presented. Signature verification against the Compute-published key set is not implemented at this revision, so no cycle runs. |
| 503 | self_check_failed | The boot self-check did not pass, so the health document reports the failure instead of a receipt. |
| 505 | http_version_not_supported | The request declared an HTTP version this door does not admit. |
Head budget
A request head larger than 16 KiB is refused as malformed.
Body budget
A body larger than 64 KiB is refused before any route is consulted.
One request per connection
The answer is written and the connection is closed; bytes past the declared body are never read as a second request.
Connection budget
Ten seconds of read and write time per connection, so a slow client costs one bounded connection.
Scheduled work
The cycle is declared, and paused.
One daily cycle is declared for the door. Pausing is the honest posture at this revision rather than a silent skip: while the row is paused, the platform fires nothing, and a forced tick is recorded as succeeded without firing.
What the declared row says
- One wake a day, after the day’s results are published; the tick is the cycle’s only trigger.
- The wake posts to this door’s wake route, and carries a signed tick the door must verify before a cycle runs.
- Overlapping ticks are skipped and a missed tick is not caught up later.
- A bounded number of delivery attempts per tick; Compute owns the tick ledger and the receipts.
- The row is paused. Read the cycle back through the cycle receipt, not through the tick row: a forced tick on a paused row can be recorded as succeeded without firing anything.
What unpausing requires
All of the following, in this order. Until every one holds, the schedule stays paused and the wake keeps refusing.
- 01An image has been built from the declared recipe, and its digest is pinned as runtime posture rather than addressed by a floating tag.
- 02Every run image the cycle submits is pinned the same way.
- 03The door verifies the signed Compute tick: a bearer token signed for this door, checked against the key set Compute publishes, with the audience pair matching the door’s own address.
- 04The project’s object storage capability resolves, so a probe can report present instead of an unreachable platform.
- 05The cycle’s container submission path is implemented and proven.
- 06An operator has reviewed the posture and unpaused the schedule row.
When the door refuses you.
The troubleshooting page maps each refusal — from a refused wake to an unsealed receipt document — to what to check, and says when a refusal is the correct outcome.