Operator policies

The signed, public policy every operator publishes: what it serves, where, and what it refuses, and how a provable breach is slashed.

An operator policy is a signed, machine-readable statement of how an operator runs its service: which models it serves, in which jurisdictions, what it refuses, and how it treats request data. Every operator on Tenzro Network 1 that serves models publishes one.

The policy is the operator's own. The network does not write it, approve it or decide what content is allowed. What the network does is hold the operator to it: routers and clients can filter on it, the operator's node enforces it on every request, and a breach that can be proven from the operator's own signed receipts is slashed from its bond.

What a policy contains

json

{
  "type": ["TenzroOperatorPolicy"],
  "operator": "did:tenzro:machine:...",
  "sequence": 7,
  "validFrom": "2026-10-01T00:00:00Z",
  "validUntil": "2027-04-01T00:00:00Z",
  "receiptKeys": [{ "algorithm": "ed25519", "publicKey": "...", "binding": "..." }],
  "serves": {
    "models": ["tenzro:model:9f2c...", "tenzro:model:41ab..."],
    "requireModelCredentials": [
      { "subject": "model", "kind": "safety-scan", "issuers": ["did:tenzro:human:..."] }
    ]
  },
  "jurisdictions": ["EU", "CH"],
  "refuses": { "categories": ["org.example.no-biometric-id"], "unsafeFormats": true },
  "data": { "retentionDays": 0, "trainsOnInputs": false },
  "proof": { "...": "signed by the operator's hardware key" }
}

Field	Meaning
`operator`	The operator's hardware-derived DID. The policy is signed with the same key.
`sequence`	Increases with every new version. The newest version in force applies to later requests.
`validFrom`, `validUntil`	The window in which the policy is in force.
`receiptKeys`	The keys the operator signs serving receipts with. Each entry carries a binding signature, so no operator can claim another's key.
`serves.models`	The models served, by manifest root. Leave it out to serve any model.
`serves.requireModelCredentials`	Credentials a model must hold before the operator will load it, and whose credentials count.
`jurisdictions`	The countries or blocs requests are served from.
`refuses`	Content categories the operator declines, and whether unsafe weight formats are refused.
`data`	How long request data is kept and whether it is ever used for training.

Publishing a policy

Write the policy document for your operator DID.
Sign it with your operator's hardware key, on the machine that holds it. The node never takes your private key.
Submit the signed document to any node. Every node re-verifies it before accepting it and shares it with its peers.
Your node's DID document advertises the policy by its content digest, so anyone who resolves your DID finds the exact version in force.

A newly signed policy must be current when submitted, and its validFrom cannot precede its signing time. An operator cannot back-date a policy to cover past requests.

To change a policy, publish a new version with a higher sequence. It governs requests served after it takes effect; earlier requests are still judged against the version that was in force when they were served.

How it is enforced

By the operator's own node. Before serving, the node checks every request against its published policy. It refuses a model the policy does not list, a model that lacks the credentials the policy promises, and a request from outside its declared jurisdictions.

By routers and clients. A relying party can require that operators publish a policy, serve only from certain jurisdictions, or never train on inputs, and route only to operators whose signed policy says so. See Trust and provenance.

By the chain, for provable breaches. Every response carries a receipt signed with one of the operator's receiptKeys. The receipt names the model's manifest root, hashes of the request and response, the jurisdiction it was served from, and when it was signed.

Slashing: only for provable breaches of your own policy

Some clauses can be checked mechanically against a single receipt:

serves.models: the receipt names a model the policy does not serve.
jurisdictions: the receipt was served from a jurisdiction outside the declared list.

Anyone holding such a receipt can submit it together with the policy as violation evidence. Verification is deterministic and anyone can recompute it:

The policy's signature verifies.
The receipt's signature verifies under a key the policy lists in receiptKeys.
The receipt was signed while that policy version was in force.
The receipt contradicts the clause.

If all four hold, the operator's compute bond is slashed. Each piece of evidence can be used once, so the same breach is never punished twice. See Slashing.

Other clauses, such as content categories in refuses or data handling in data, need judgement rather than a signature check. They are public declarations that relying parties can filter on and auditors can certify against. A claimed breach of one of them opens a dispute decided by the existing dispute process; it never triggers an automatic slash.

Certifying a policy

An auditor who has reviewed an operator's practice can issue a policy-conformance credential to the operator's DID. Relying parties who trust that auditor can then require it. See Certification and ratings.