How fields interact

Context forms at two scales: fields within one event, then events across the history.

A payment’s amount has more meaning alongside its merchant and the account’s earlier activity. RelFlow builds that context at two scales: fields belonging to one event record, then events belonging to the same history. This keeps the relationship between an amount and its merchant available when the model compares transactions. The example is the collection from Add transaction history; the current payment is the final transaction, and the earlier ones were known at its decision time.

A grid of tokens with one row per transaction on May 21, May 27, and May 28 and one column per field: booked_at, amount, and merchant. The first row is framed as coordinate attention among the fields of one transaction. The amount column is framed as sequence attention across the history. An arrow leads from the grid to a learned summary labeled reduction.

A grid of tokens with one row per transaction on May 21, May 27, and May 28 and one column per field: booked_at, amount, and merchant. The first row is framed as coordinate attention among the fields of one transaction. The amount column is framed as sequence attention across the history. An arrow leads from the grid to a learned summary labeled reduction.

Figure 1: Context forms in two stages inside the branch, then a reduction decides what reaches the root.

Within one transaction

Each field first supplies an embedding at each transaction coordinate. Coordinate attention groups the direct sibling fields at the same coordinate: booked_at, amount, and merchant from the first transaction interact with one another. The other transactions have their own groups. This step allows an amount’s representation to depend on the merchant attached to that amount.

disputed=rf.Boolean(mask=True) keeps every dispute label out of the inputs and supervises every retained transaction; the labels are never evidence.

Two histories can have the same total spend and merchant counts while pairing the larger purchase with different merchants. Keeping each transaction’s fields together preserves that distinction as evidence for learning.

The coordinate encoder operates on active direct leaf fields. A nested branch contributes its own representation later; it does not join this group of direct fields. When fewer than two active direct fields are available, there is no coordinate interaction to perform. Setting branch attention to None also disables this encoder.

Across the history

After coordinate attention, the branch concatenates its children’s tokens into one sequence and applies its sequence encoder. Tokens from different history positions can now interact. Across a longer history, the model can learn patterns such as repeated purchases at one merchant, changing amounts, or activity concentrated in a short period. Whether these patterns help predict a dispute must be checked on held-out payments.

These two stages answer different questions:

Stage Available context Example relationship
Coordinate attention Direct fields of one transaction Which merchant received this amount?
Sequence attention Present child tokens across the branch How does this transaction compare with earlier ones?
Branch reduction The branch’s encoded transactions Which context should reach the observation root?

Reduction is a separate step, described in Branch summaries. With the default reduction, trxns passes a learned summary to its parent. That summary includes the earlier and latest transactions; the root has no duplicate amount or merchant fields. The summary is trained for the model’s objectives; it is not a readable transaction ledger or a guaranteed calculation of a business statistic.

Presence and position

Padding represents an absent coordinate. The encoder excludes it from attention and restores zero output at absent positions. A null value at a present coordinate has its own field state; replacing it with zero changes what the model observes. See field states.

Rotary position information gives attention a signal about token positions. booked_at=rf.DateParts(dateparts=["day_of_month", "day_of_week", "hour_of_day"]) supplies calendar cycles, not elapsed time. Input ordering still belongs to the application, as Prepare observations describes; position information does not repair an incorrectly ordered collection or prevent future information from entering the inputs.

Sequence attention can use the complete retained collection, because every prediction in this example shares one review cutoff.

Encoder updates use residual attention and feed-forward blocks with RMSNorm and tanh GELU. Attention normalizes each head’s projected queries and keys before applying rotary positions, so attention logits do not grow with projection scale. Architecture options and collection limits belong in the model tree and Branch reference.

Next, follow the encoded transactions through Branch summaries.