FAO delivery path is point/DataFrame-based — won't carry rusty_bucket's pooled draws

[Polichinel]

Problem

The unfao delivery manager (views_postprocessing/unfao/managers/unfao.py) is built around point forecasts:

• _read_forecast_data (~L62-100) downloads a single parquet DataFrame from Appwrite and wraps it in PGMDataset (pandas).
• _append_metadata (~L112-122) joins GAUL metadata onto that DataFrame.
• _save (~L206-223) writes pred_*_best / pred_*_prob point columns.

rusty_bucket (views-models#143) is the opposite by design: a PredictionFrameEnsembleManager + aggregation: concat ensemble that ships the full pooled posterior draws (~1024/cell, Track A y_pred.npy of shape (N, S)) uncollapsed, so the principled MAP/HDI collapse happens once downstream in views_frames_summarize.

So the current FAO delivery path would not carry rusty_bucket's draws — it expects a point DataFrame with _best/_prob columns, not (N, S) draw arrays. This is the downstream half of the views-models#143 contract: "the FAO delivery path must not collapse them."

Scope

• Adapt the unfao delivery to read/carry the pooled draws (frames / (N, S) arrays + identifiers) for rusty_bucket, delivering them uncollapsed.
• Keep the metadata enrichment (GaulLookupEnricher) and validation working on the frames/draws path.
• Decide the delivery artifact to FAO (raw draws vs the views_frames_summarize collapse output).

Not blocking yet

rusty_bucket's constituent models are still being tuned (views-models#143), so this is track-and-scope. It must land before rusty_bucket goes live.

Refs

• views-models#143 (rusty_bucket + the downstream draw-preservation contract)
• views_postprocessing/unfao/managers/unfao.py (_read_forecast_data, _append_metadata, _save)
• Related: C-40 in the register (the manager's pipeline-core coupling), which any rework here should keep in mind.

[Polichinel]

Cross-repo note from the views-faoapi side — this issue is the keystone for faoapi going frame-native.

Confirmed end-to-end: unfao/managers/unfao.py _save → to_parquet() on the object-dtype DataFrame is exactly where the nested-array-sample parquet that faoapi consumes is born. Downstream, faoapi does the inverse dance — pd.read_parquet → _convert_to_arrays (decode each object-dtype cell back into an np.ndarray) → (N_time, N_entity, S) tensor (views-faoapi data/handlers.py ~234, ~467–516). So the object-dtype round-trip is pure overhead on both ends.

Suggested solution shape (so it unblocks the consumer cleanly):

• Emit a native views-frames frame carrying the full (N, S) pooled draws uncollapsed (as you note for rusty_bucket), and let the principled MAP/HDI collapse happen once in faoapi via views_frames_summarize (tower_point/hdi_tower — see views-faoapi#89).
• Use the arrow single-file form (views_frames.io.arrow), not the npz multi-file directory — Appwrite buckets are file-oriented (one blob per artifact).
• Carry the 9 GAUL metadata columns in the frame header/sidecar, not as DataFrame cells.

This is the producer half of the wire-format change; the faoapi consumer half + the ADR-046 amendment are tracked in views-faoapi (new issue, linked). Resolving this is what actually lets faoapi retire its parquet decode.