# Wrangled Operand Tuples Codec

The single accumulate ${\bf o}$ input depends on **Wrangled Operand Tuples** coming out of refine work results:


This ${\bf o}$ input is inside ${\cal E}(t, s, \updownarrow {\bf o})$


where:

* $t \in \mathbb{N}_T$ - time slot
* $s \in \mathbb{N}_S$ - service
* ${\bf o}$ - the set of wrangled work results

It is detailed [here](https://graypaper.fluffylabs.dev/#/5f542d7/171903171903)


This expression is **missing** in GP:

${\cal E}({\bf o} \in \mathbb{O}) = {\cal E}(O({\bf o}_{\bf o}), l, k, {\bf a})$

but

Here is C.23:


This does NOT appear to help refine the above ${\cal E}({\bf o} \in \mathbb{O})$ expression though:


So we are on our own.

The first piece of 12.18 is:


then the other 3 pieces are from ${\bf p}$:
* $l \in \mathbb{H} : {\bf r}_l$
* $k \in \mathbb{H} : (w_s)_h$
* ${\bf a} \in \mathbb{Y}: w_o$

so the MISSING expression is:

${\cal E}({\bf o} \in \mathbb{O}) = {\cal E}(O({\bf o}_{\bf o}), {\bf r}_l \in \mathbb{H}, (w_s)_h \in \mathbb{H}, w_o \in\mathbb{Y})$

We don't exactly have a JAM decoder in PVM accumulate to decode all that. But the first piece has a type discriminator ( 1-byte .. not sure) followed by a probably tiny number of $o$ bytes (if $o \in \mathbb{Y}$), then the next 2 pieces ${\bf r}_l$ and $(w_s)_h$ are 32 bytes (thus easily "manually" parsed) and the remaining bytes are $w_{\bf o}$. This parsing is what is required in the implementation of an accumulate service. Whew!