Filed from CIRISStatus, which monitors this service. Companion issues on CIRISBilling and CIRISDepot — post-3.0 those three (input, output, billing) are the long-term monitored set.
What changed on our side, and why it points here
ciris-status used to emit health:liveness:v1 attestations naming its own key as the attested subject — the monitor attesting about the monitor. persist's family rule for that dimension is witness_relation MUST be external — a service never attests its own liveness (attester != attested), and persist v31 now ships that ban built and wired into check_reserved_prefix_admission. It only still admits us because the gate reads the row's attestation_type ("scores") rather than the envelope dimension. One line moves and it stops.
We cut over to first-person claims instead (CIRISStatus#55): observation:reachability:v1, where the subject is our observation, which we genuinely own. That is honest and it ships. What it cannot say is anything about you: a monitor can sign "I got 200 in 84ms from the proxy", but "the proxy is healthy" is a claim about a subject that must resolve to a registered key.
The ask
Give CIRISProxy a federation identity, so a witness can attest health:liveness:v1 about it.
Concretely, persist requires two things (check_attested_subject_admission + CIRISPersist#659):
- the attested subject must be a row in
federation_keys, and
- its registration envelope must bind its own
key_id, identity_type, and both pubkeys (Ed25519 + ML-DSA-65) — signed by the subject.
That second point is why we cannot do this for you. Minting a keypair on your behalf and signing your registration would make every "proxy" claim in the fabric actually ours. The key has to be yours.
Two shapes, pick by how far you want to go:
- Minimal — hold a keypair, sign your own registration once. Generate hybrid Ed25519 + ML-DSA-65 keys, produce the signed
KeyRecord, hand it over once; the monitor registers it and can then attest about you by name. No node, no corpus, no runtime dependency.
- Full — become a node.
ciris_server exposes serve_with_python_adapter to Python (the shape CIRISAgent uses), and serve_with_adapter self-registers the node's derived key at boot, so registration stops being a manual step. This is what ciris-status itself does.
Please don't re-implement hybrid signing — a second implementation of federation-tier verification fails silently and differently from the substrate.
The second, more interesting half
Today our provider rows are derivative: we never touch Groq or OpenRouter, we touch /v1/status and the proxy tells us. Our new envelopes are explicit about that — epistemic_mode: derivative, via: service:us.proxy, lower confidence — because collapsing hearsay into first-person claims is how one proxy outage reads as eight provider outages.
But the proxy has first-person knowledge of its own upstreams: it makes those calls. Once the proxy holds a key, it can attest its own provider observations directly, and the monitor can stop laundering them. That is strictly better evidence than anything we can produce from outside, and it is the thing that would let a second monitoring vantage disagree with us usefully.
Not urgent, but not indefinite
Nothing breaks today. The trigger to watch is persist keying that self-emission gate on the envelope dimension, at which point health:liveness becomes unavailable to anyone attesting about themselves — including any future self-report you might have reached for instead.
Background: FSD/MULTI_VANTAGE.md §2 D5 carries the decision, the verification against persist v31.2.0, and what each option costs.
Filed from CIRISStatus, which monitors this service. Companion issues on CIRISBilling and CIRISDepot — post-3.0 those three (input, output, billing) are the long-term monitored set.
What changed on our side, and why it points here
ciris-status used to emit
health:liveness:v1attestations naming its own key as the attested subject — the monitor attesting about the monitor. persist's family rule for that dimension is witness_relation MUST be external — a service never attests its own liveness (attester != attested), and persist v31 now ships that ban built and wired intocheck_reserved_prefix_admission. It only still admits us because the gate reads the row'sattestation_type("scores") rather than the envelope dimension. One line moves and it stops.We cut over to first-person claims instead (CIRISStatus#55):
observation:reachability:v1, where the subject is our observation, which we genuinely own. That is honest and it ships. What it cannot say is anything about you: a monitor can sign "I got 200 in 84ms from the proxy", but "the proxy is healthy" is a claim about a subject that must resolve to a registered key.The ask
Give CIRISProxy a federation identity, so a witness can attest
health:liveness:v1about it.Concretely, persist requires two things (
check_attested_subject_admission+ CIRISPersist#659):federation_keys, andkey_id,identity_type, and both pubkeys (Ed25519 + ML-DSA-65) — signed by the subject.That second point is why we cannot do this for you. Minting a keypair on your behalf and signing your registration would make every "proxy" claim in the fabric actually ours. The key has to be yours.
Two shapes, pick by how far you want to go:
KeyRecord, hand it over once; the monitor registers it and can then attest about you by name. No node, no corpus, no runtime dependency.ciris_serverexposesserve_with_python_adapterto Python (the shape CIRISAgent uses), andserve_with_adapterself-registers the node's derived key at boot, so registration stops being a manual step. This is what ciris-status itself does.Please don't re-implement hybrid signing — a second implementation of federation-tier verification fails silently and differently from the substrate.
The second, more interesting half
Today our provider rows are derivative: we never touch Groq or OpenRouter, we touch
/v1/statusand the proxy tells us. Our new envelopes are explicit about that —epistemic_mode: derivative,via: service:us.proxy, lower confidence — because collapsing hearsay into first-person claims is how one proxy outage reads as eight provider outages.But the proxy has first-person knowledge of its own upstreams: it makes those calls. Once the proxy holds a key, it can attest its own provider observations directly, and the monitor can stop laundering them. That is strictly better evidence than anything we can produce from outside, and it is the thing that would let a second monitoring vantage disagree with us usefully.
Not urgent, but not indefinite
Nothing breaks today. The trigger to watch is persist keying that self-emission gate on the envelope dimension, at which point
health:livenessbecomes unavailable to anyone attesting about themselves — including any future self-report you might have reached for instead.Background:
FSD/MULTI_VANTAGE.md§2 D5 carries the decision, the verification against persist v31.2.0, and what each option costs.