{
  "signed_version": "1.1.1",
  "what_this_lane_is": "Submissions signed by a key this deployment does not hold. The open lane at /x/witness/observe proves somebody handed us a tip. This lane proves the holder of a specific private key did - including against us, because we only ever hold the public half.",
  "why_it_exists": "The HMAC lane binds a name to a shared secret, and a shared secret is held by both parties. It closes third-party submission under your name and does not close operator submission under your name. This lane closes both, and it does so by arithmetic rather than by our promise.",
  "steps": [
    "1. Generate an Ed25519 keypair. Keep the private half. It never leaves your side and we have no route that accepts one.",
    "2. POST /x/signed/enroll with {\"chain\":\"<name>\",\"pubkey\":\"<64 hex>\"}.",
    "3. Build the canonical message, sign it, and POST /x/signed/submit with {\"chain\",\"tip\",\"ts\",\"signature\"}.",
    "4. GET /x/signed/verify?peer=&tip= for the receipt, which carries everything a third party needs to recheck it without us."
  ],
  "canonical_message": {
    "submit": "aileash-signed-v1\\n<chain>\\n<tip>\\n<ts>",
    "rotate": "aileash-rotate-v1\\n<chain>\\n<new pubkey>\\n<ts>",
    "encoding": "UTF-8, single \\n between lines, no trailing newline. ts is integer epoch seconds."
  },
  "replay_controls": {
    "max_age_seconds": 900,
    "max_future_seconds": 120,
    "monotonic": "ts must be strictly greater than the last ts accepted for the name",
    "duplicate_signatures": "refused"
  },
  "on_acceptance": {
    "receipt_seq": "An integer, never null, incremented by exactly one for each accepted submission UNDER THIS NAME on this lane. Issued inside the same lock that writes the record, so a number is never spent on a submission that was not stored. Two receipts numbered N and N+2 prove a third exists that you did not receive. The current highest is published at /x/signed/keys, so the check does not depend on asking us.",
    "receipt_seq_scope": {
      "values": [
        "per-peer",
        "per-name",
        "per-chain"
      ],
      "per-peer": "issued per registered peer_id. Used by /x/peer/submit.",
      "per-name": "issued per bound name. Used by /x/bind/submit.",
      "per-chain": "issued per enrolled chain name. Used by /x/signed/submit.",
      "why_it_is_here": "The three signed lanes each count within their own scope, so a receipt carries the scope of its own sequence rather than requiring the holder to remember which lane produced it. The set is closed: a value outside this list is an error on our side, not a new scope you should widen a schema for.",
      "not_comparable_across_scopes": "Two receipts with different scopes are counting different things and their numbers say nothing about each other."
    },
    "key_seq": "The server-wide per-API-key sequence, which is null on this lane and always will be. That counter lives on an api_key row, and this lane files under a label rather than a key because it authenticates by signature and issues nobody an account. It is returned rather than omitted so the absence is visible instead of inferred. Before 1.1 this null was reported as receipt_seq, which made a missing property look like a broken field.",
    "sequence_survives_rotation": "Rotating the key does not reset the sequence. It belongs to the name's submission history rather than to the key, so a rotation cannot be used to erase a gap.",
    "seal_failure": "If the audit chain does not seal your submission you get 500 seal_failed with the reason, and nothing is recorded - no sequence number, no log row, no receipt. Send a fresh submission with a later ts once the fault is fixed. A receipt you cannot verify is worse than no receipt, so this lane will not issue one.",
    "two_different_completeness_claims": "receipt_seq is about completeness of the receipts WE issued to you. It says nothing about completeness of the records YOUR chain sealed, which no signature can reach and which is listed under honest_limits."
  },
  "this_lane_rejects": "Unlike the open lane, a submission that does not verify is refused and nothing is sealed. Writing an unverifiable signature into a name's history is the harm, not the protection.",
  "key_rotation": "A rotation must be signed by the key being replaced. Nobody who lacks the current private key can rotate it, this deployment included, and every rotation is sealed with both keys recorded.",
  "honest_limits": [
    "Does not prove the records behind the tip are true.",
    "Does not prove the peer's own chain is complete. Catching an omission there needs an audit protocol, not cryptography.",
    "Does not prove who the keyholder is in the world - only that the same party signed each time.",
    "Enrolment is open, so the first party to enrol a name gets it. An enrolment over a name already seen in the open lane is flagged permanently, which is detection and not prevention.",
    "receipt_seq proves you are missing a receipt. It does not prove why, and it cannot distinguish a lost response from one that was never sent."
  ],
  "changed_in_1_1_1": [
    "receipt_seq_scope is now a bare token from a closed set - per-peer, per-name, per-chain - rather than a sentence, and the set is published so a closed schema can pin an enum. Asked for by Philip Pinol (PRAXIS). Value change only; the response shape is unchanged from 1.1."
  ],
  "changed_in_1_1": [
    "receipt_seq is a real per-chain gapless sequence issued by this module, not the api_key counter that was always null here because this lane files under a label rather than a key. The completeness property applies to this lane for the first time.",
    "The api_key counter is still returned, as key_seq, and is null by design so the absence is stated rather than hidden.",
    "A failed seal returns 500 and records nothing, instead of returning a receipt with no block behind it.",
    "Enrolment and rotation report sealed true or false with the error, rather than sealing as a side effect and ignoring the outcome.",
    "/x/signed/keys publishes latest_receipt_seq per name."
  ],
  "what_this_proves": "That the holder of the enrolled private key produced this exact statement - name, tip and timestamp - and that we sealed it at the recorded time. This deployment holds only the public key and cannot produce such a signature, so it is not a claim you have to take on our word. Recheck it yourself with any Ed25519 library.",
  "what_this_does_not_prove": "Nothing about whether the records behind the tip are true, nothing about whether the peer's chain is complete, and nothing about who the keyholder is in the world. It proves the same party signed each time."
}