Host your model

What the platform sends

• A blast's case, holding only the inputs your manifest declares, as POST /runs.
• Only when someone on the team asks: “Run connected models” on a blast, or a backtest. Never because a blast changed.
• Every request signed with the platform's Ed25519 key, with an Idempotency-Key that is the same on every retry of one run.
• A callback URL of the run's own, if you answer 202. Keep it private: it identifies the run.

What it never sends

• An input your manifest does not declare, not even during conformance.
• Who asked for the run, or anything else about the team's people.
• A shared secret. Nobody holds the other side's private key.
• An Authorization header. Your host must be reachable without one.

What the platform keeps

• Your manifest as it was connected, and its hash, to tell when it changes.
• The public keys your manifest declares, to check your callbacks.
• Your answers, as the team's records beside the platform's, without provenance.parameters.
• The build.hash you report, with every result.
• When each request was sent and answered, and how it ended.

What your host must do

• Check the signature on every request but /healthz, against the keys at /developers/keys/v0.json.
• Answer POST /runs within 30 seconds, or answer 202 and call back, signed with your key.
• Keep each run readable at GET /runs/{id} for 24 hours: the platform asks there when a callback is late.
• Answer the same case the same way, and a repeated Idempotency-Key with the original run.
• Decline what you cannot answer, and say why, rather than guess.
• Change nothing under a version you have connected. A manifest, or a build answering, that changes under the same version stops the model's runs until it is put back or a new version is connected.
• Rotate your key in three steps: make the new one yourself (openssl genpkey -algorithm ed25519), publish and connect a version that lists both while still signing with the old, then sign with the new (HOST_SIGNING_KEY, or replace data/host-key.pem) and drop the old in the next version.

Start from a template

The templates do all of the above: a Node server with no dependencies and a Python one needing only cryptography, each with a worked-example model to replace. bootstrap.sh downloads one onto a fresh box. On its first start a template makes its key in data/host-key.pem and prints the signing block to paste into manifest.json. From then on it serves exactly the keys listed there, and will not start without its key file (or HOST_SIGNING_KEY) or with a key the list leaves out, so a lost key never becomes a new one under the same version.

• server.mts
• model.mts
• server.py
• model.py
• requirements.txt
• manifest.json
• bootstrap.sh

curl -fsSL https://app.shockai.co/developers/templates/v0/bootstrap.sh | sh -s -- node
PUBLIC_ORIGIN=https://models.example.com BUILD_HASH=$(git rev-parse --short HEAD) node shockai-model/server.mts

Before you connect

• Your team has Team models and Connected models switched on. How a team gets them.
• Your team has its model namespace, which ShockAI assigns with Team models. The id in your manifest starts with it.
• Your manifest offers at least one kind the platform lists a model by: receiver_ppv, max_charge, airblast or movement_field.
• Its pricing.model is included or licence.
• Its dataHandling keeps nothing and never trains on a case: retention is none and trainsOnCustomerData is false. Every case sent says the same.

Connect it

1. Run your host at an https address on the default port, reachable from the internet.
2. A manager of the team opens Models in team settings, chooses Your code, hosted under Add a model, and gives the address with its base path.
3. The platform reads your manifest and runs the conformance suite against your host. Each check is a real run.
4. Once it passes, the team's owner reads what will be sent where, agrees, and publishes it.