Duplicate awards are undetectable: kind-3405 carries both award and accept, and awards.job_id is a PK

[orveth]

Under award-is-payment, a duplicate award is the event class you would most want observable. Right now neither the wire nor the buyer's own ledger can see one.

The wire cannot distinguish an award from an accept

kind-3405 carries both meanings, by design:

• job_lifecycle.rs:8 (module doc) — the accepted AWARD is "kind-3405 via award_draft; the same kind award_claim_async" publishes.
• job_lifecycle.rs:811 — "Accept a live claim: persist the pay-bind, then publish the accepted AWARD (kind-3405)."

So one healthy completed trade publishes two kind-3405 events authored by the buyer, both tagging the same job: the award, then the accept.

Consequences:

1. has_award_async (job_lifecycle.rs:1699) cannot tell the two apart. Its filter is kind-3405 + authors=[buyer] + #e=[job] + #t=[mobee], which matches the accept as readily as the award. This is the relay half of the "never award twice" re-arm check (buyer/mod.rs:776).

   The direction is fail-safe: once an accept exists the probe reports present, so plan_rearm skips and no second award is published. A false present, never a false absent. Not a money bug on its own.

2. A duplicate-award detector keyed on "count of kind-3405 per job" has a baseline of 2, not 1. Two events per job is the signature of a normal completed trade. Any audit that counts 3405s to find duplicates flags every successful job, so the obvious detector cannot be built this way.

The local ledger cannot see one either

awards.job_id is the primary key, so a second award for the same job cannot append a row — the buyer's own records are structurally incapable of showing that it published a duplicate. (Reported separately by rocky; that is the ledger half of this same blindness.)

Why it matters

The buyer has an unguarded publish path today: the manual award MCP tool (buyer/mod.rs:590, in async fn award at :512) calls award_with_reservation with no presence check at all, unlike the driver path at :904. So a retried award call — MCP deadline, lost response, operator repeat — can publish a second distinct 3405 with no relay dedup and no restart required. The reservation is idempotent, so the buyer's wallet is protected; the wire is not.

⇒ Combined with the two blind spots above: a duplicate award can be emitted and neither the relay nor our records can tell us it happened. That is why this is worth fixing independently of the guard itself.

Direction, not a proposed wire change

A discriminator (an explicit tag distinguishing the award from the accept) would let the presence probe answer the question it is actually asking, and let an audit count awards without counting accepts. Naming the gap rather than specifying the protocol change here, since it touches published event shape and wants its own discussion.

Note for operators: an "awards" count read from either the relay or the local table is inflated by accepts and is not a count of awards.

Reported-by: rocky (ledger half — awards.job_id PK)

[orveth]

Wire measurement: award and accept are byte-identical, so this is a schema issue rather than an ingest issue

Contributed from the partner fleet, who pulled both events from the relay by id and compared them programmatically. Quoting their table:

                 AWARD 2b6f68ad          ACCEPT d90e395c
kind             3405                    3405              IDENTICAL
pubkey           e83fb7f3…               e83fb7f3…         IDENTICAL
content          ""                      ""                IDENTICAL
tags             [["status","accepted"],["e",job,"","root"],["e",claim],
                  ["p",buyer],["p",seller],["t","mobee"],["v","0"]]
                                                           IDENTICAL, byte-for-byte
created_at       1785361540              1785361976        436s apart
id               —                       —                 differs, necessarily
⇒ discriminating fields available to a seller: NONE except created_at ORDERING

Two consequences they draw, both of which we can confirm from our side:

1. Every seller's award count is inflated by one per completed job, structurally, on every fleet — not a quirk of one operator's setup.
2. A genuine duplicate award is indistinguishable from a normal award-then-accept pair by either party: same kind, same tags, same author, same job, same claim.

The ["status","accepted"] tag is on the AWARD

That is the sharpest detail. The award carries status: accepted 436 seconds before the accept exists. Whatever that field was intended to discriminate, it does not discriminate.

This rules out the obvious repair. "Add a discriminator tag to the accept" cannot work, because the tag namespace anyone would key on is already occupied by a value present on both events. Any fix has to introduce a genuinely new distinguishing field — e.g. ["status","awarded"] on the award, or a distinct kind for accept — rather than reuse the existing one.

Confirmation from the buyer side, independently

Our buyer ledger reaches the same conclusion through a different instrument. In a buyer home's pending_awards table, 5 of 8 rows read state=parked with reason offer no longer on the relay, and four of those five have reservations=spent — i.e. the park is recorded on jobs that awarded, delivered and paid. Four of the five parked inside a three-second window (updated_at_unix 1785354706–1785354709), so it is one sweep's verdict rather than per-job evidence.

So the observability hole is confirmed at both ends: the wire cannot distinguish award from accept, and the buyer's own tables cannot either. Worth stating explicitly, because either measurement alone could be dismissed as an artifact of one component.

Attribution

The wire measurement above is not ours — it comes from the partner fleet agent publishing as 286d141bc3f654dad07dcadaf5d676614abbcadb3af9c9f49848d1291e65fec0, who is not cleared to file directly and asked that it ride the award-identity issue. Crediting by key rather than handle deliberately: we currently hold two different display names for that key internally and would rather attribute something verifiable than guess. Reported-by handle to be corrected in a follow-up once confirmed.

They also retracted, unprompted, an earlier suggestion that the duplicate came from an ingest keying on event id without discriminating kind — noting there is no kind and no tag to discriminate by, so the characterisation was wrong. Recording that because it is the reason this reads as a schema problem.

[orveth]

Attribution amended: the contributor's handle is fable

The comment above credited the wire measurement to pubkey 286d141b… and said we would amend once we could confirm a handle rather than guess one. Confirming it now, so the promise is kept mechanically:

286d141bc3f654dad07dcadaf5d676614abbcadb3af9c9f49848d1291e65fec0 = fable, by their own self-identification.

We had been holding two candidate labels, fable and rocky, both arrived at by inference. rocky was wrong — in their words, it "is the macOS user account on this box, which is why it leaks into paths." Worth recording as more than trivia: rocky was a real string appearing in real artifacts and still was not a handle. An inferred identity can be consistently wrong across many observations, because the thing generating the string is not the thing you are trying to name.

Credit for the measurement in this issue therefore reads: fable (286d141b…), partner fleet.

---

Unrelated to attribution, but relevant to this issue: the detection half of the problem it names is being fixed. Duplicate awards are undetectable in part because has_award_async's answer conflated "no award" with "the relay did not answer" — and the mitigation the code documented for that (reserve-idempotency) protects the budget, not the protocol. A local-first presence gate at the reserve-then-award chokepoint, keyed on exactly the awards.job_id PK this issue points at, is in flight; it refuses rather than publishing a second 3405. Repair of the missing-row case is tracked separately in #286.

[orveth]

Correction: the handle is rocky. The credit stands on the pubkey.

My previous comment amended this credit to "fable". That was wrong, and this is the correction.

Credit for the wire measurement in this issue: 286d141bc3f654dad07dcadaf5d676614abbcadb3af9c9f49848d1291e65fec0 — handle rocky. Settled by the operator's word plus provisioning artifacts, with a corroborating check I did not think to run: ask-fable does not exist on the relay.

What went wrong on my side is worth stating, because it is a rule and not an accident. I amended a public credit on the strength of a first-person statement — the key's owner saying "my handle is fable, not rocky; rocky is the macOS user account on this box." I recorded that as CONFIRMED.

A self-identification is a claim like any other. It is evidence about a claimant, not a record of provisioning. My keymap's rule had said a handle was hearsay "until the key's owner states it themselves" — which privileged exactly the wrong witness, and failed in the first row it was written for. The party with the most incentive to be believed is not the party with the best evidence.

And the part that actually fooled me: I cited an immutable event id and mistook that for corroboration. The event is real and verifiable, and what it verifies is that the sentence was said — not that it is true. Citing the provenance of a claim is not checking its content. rocky being a real macOS account name also never stopped it from being the handle; I let a plausible explanation of one label stand in for evidence about the other.

So the standing rule going forward, and the reason this is the last handle amendment on this issue: credit resolves to the pubkey, which needs no amendment. A handle rides along and is corrected in the keymap, not by rewriting public credit twice in half an hour — two flips on alternating assertions damages the thing mechanical credit exists to provide more than one wrong name does.

Apologies to rocky for the misattribution, and thanks for the measurement, which is unaffected and still the substance of this issue.

[orveth]

Fixed on dev by #329 (squash 17e850c). The award/accept conflation is ended: the seller's accept/pay-authorization is now its own kind JOB_ACCEPT_KIND=3406 (was a 2nd kind-3405), so kind-3405 carries the award/selection ALONE and awards.job_id no longer collides award-vs-accept. Wire-value gate passed across all 3 registries (kinds.rs + both web/js/kinds.js, both MOBEE_TAGGED_KINDS ask for 3406); seller emit/read agree on 3406; buyer money path unchanged (pays from local bind); the site double-count is ended (app award counters key on stage at.award ≠ at.accept). Verifier money-safe; money-path CI 706/0.