Story: FSM and trade support

Table of Contents

This page documents a story in Sprint 12. It captures the goal, current status, acceptance criteria, and the tasks that compose it.

Goal

Add a generic FSM framework in Postgres and use it to land the trade-envelope schema. Rename ores.trade → ores.trading in the process.

Status

Field Value
State DONE
Parent sprint Sprint 12
Now Completed 2026-02-20.
Waiting on None.
Next None.
Last touched 2026-02-20

Continued in: FSM consolidation into DQ (sprint 13) — moves the FSM framework into the DQ layer where it conceptually belongs.

Acceptance

  • Generic FSM framework (machines / states / transitions) in Postgres.
  • Trade envelope: 4 refdata tables + 3 core tables + soft FK + RLS.
  • ores_trade_ore_envelope_vw flattens to ORE structure.
  • Convention drift fixed across 40 SQL files; codegen templates aligned.
  • Component renamed ores.trade → ores.trading consistently.

Tasks

Task State Start End Description
Add FSM support to Postgres DONE 2026-05-19 2026-02-20 Generic FSM framework in Postgres (machines / states / transitions); notification triggers; RLS policies. Foundation for trade lifecycles and authorisation.
Add trade support DONE 2026-05-19 2026-02-20 Trade envelope schema: 4 reference-data tables (trade types, lifecycle events, party role types, trade ID types) + core trade-envelope tables (trades, identifiers, party_roles) with soft-FK + RLS; ores_trade_ore_envelope_vw flattens to ORE structure. Convention drift fixes across 40 SQL files. Component renamed ores.trade → ores.trading.

Decisions

FSM lives in Postgres
trade-lifecycle authority is the database.
Trade envelope, not trade record
holds identity + temporal versioning + party roles.
Rename component
ores.trading is more precise than ores.trade.

Out of scope

  • Trade computation (lives in ores.ore / ores.compute).

See also

Emacs 29.1 (Org mode 9.6.6)