HMAC-signed webhooks from the six sibling apps · composite idempotency key (source_system, idempotency_key) · siblings push, i3 owns the meaning (law 6)
14 of 31 topics do not exist upstream yet. Every one is marked exists_upstream = FALSE and posts nothing, so an absent contract can never be mistaken for a quiet one (ruling L18). ops2 owes 6 reverse topics and the Influencer Hub owes all 4. The i3 subscription must be registered before any topic is switched on or the first hours vanish with no trace on either side (defect D3).
partialops2fulfillment
Topics registered13
Exist upstream6 / 13
Signature health100%
Lag p954.2s
Backlog0
Only the 6 inbound-warehouse topics exist. All 6 reverse-logistics topics are owed. Fire-and-forget by design, so orphan half-pairs need the 15-min poller.
healthyCSDcs_dashboard
Topics registered7
Exist upstream7 / 7
Signature health100%
Lag p951.8s
Backlog0
Reservation payload still sends skus[0] and quantity 1 (defect D16). i3 rejects a single-SKU claim on a multi-line case rather than accepting a partial truth.
secret staleGRN appretail receiving
Topics registered4
Exist upstream4 / 4
Signature health3 fails
Lag p952.4s
Backlog3 blocked
Rotated on their side at 09:14, not on ours. Blocked, never dropped: replay after the secret lands. Secret is [see ~/.env.master].
pollerIWMSinside ops2
Topics registered6
Exist upstream6 / 6
Signature healthinternal
Lag p9538m
Backlog142
Polled, not pushed, until the outbox PR ships (T-04.21). Merges into i3 at Phase 5 and this card disappears.
healthyRFID appabsorbed
Topics registered1
Exist upstream1 / 1
Signature health100%
Lag p950.9s
Backlog0
Absorbed at Phase 6, not re-pointed. Cannot write atomically today (defect D22), so i3 owns the transaction after absorption.
no emitterInfluencer Hubmarketing
Topics registered4
Exist upstream0 / 4
Signature healthbearer, not HMAC
Lag p95-
Backlog-
7 inbound routes, zero outbound emitter. i3 reads the Hub instead until it can push. 4,381 of 6,608 gifts are already Shopify orders, so a gift topic would double-deduct.
Topic register
14 not yet emittable
Source
Topic
Exists upstream
Retry
Posting allowed
Phase
24h
ops2
carton.created
yes
DLQ
yes
5
1,842
ops2
carton.moved
yes
DLQ
yes
5
3,104
ops2
carton.qc_outcome
yes
DLQ
yes
3
218
ops2
transfer.delivered
yes
fire-forget
qty absent
4
64
ops2
rts.opened
yes
DLQ
yes
3
7
ops2
order.dispatched
no
-
blocked
1
0
ops2
order.delivered
no
-
blocked
1
0
ops2
order.rto
no
-
blocked
2
0
ops2
order.refulfilled
no
-
blocked
2
0
CSD
case.intake_created
yes
DLQ
yes
2
41
CSD
case.item_received
yes
DLQ
yes
2
33
CSD
case.exchange_issued
yes
DLQ
yes
2
12
CSD
case.repair_closed
yes
DLQ
yes
2
4
GRN
receipt.counted
yes
DLQ
sig fail
3
18
IWMS
picking.replenished
yes
poll
no ledger row
5
96
IWMS
count.approved
yes
poll
no ledger row
5
11
RFID
unit.gate_read
yes
DLQ
yes
6
4,812
Hub
gift.dispatched
no
-
blocked
7
0
Hub
loan.returned
no
-
blocked
7
0
19 of 31 shown · blocked topics post nothing and are never silently skipped
10,447
How a key is formed, per sibling
Uniqueness is (source_system, idempotency_key), so two siblings may use the same string without colliding.
ops2 ops2:<awb>:<line_id>:<stage>
CSD csd:<case_id>:<line_id>
Shared across the exchange-out and refund legs. That sharing is what makes the double-deduct impossible.
GRN grn:<grn_number>:<line_id>
Keyed on the receipt, not the PO line, so a split delivery posts twice as it should (defect D10).
IWMS iwms:<carton_event_id>
RFID rfid:<epc>:<read_ts>:<device>
Hub hub:<deal_id>:<line_id>
When a sibling supplies no key: i3 derives one from a canonical hash of the payload's identifying fields and records key_source = 'derived'. A derived key is honest but weaker, because a sibling that changes an unrelated field produces a new key and a duplicate post. That is why the KPI tracks the header-versus-derived split.
Idempotency key source
header sibling asserts itderived i3 infers it
The invariant
A topic that does not exist upstream posts nothing and says so. The register carries exists_upstream with a CHECK, so i3 cannot claim a readiness the sibling has not delivered.
This exists because the master plan listed 7 ops2 topics as an existing contract and ops2 has 6, all inbound-warehouse (ruling L18). A missing contract and a quiet one look identical in a feed. They must not look identical here.