Question #
Which contract should own B1 accounting traffic?
- Separate account-graph carrier. Keep money on the account graph, replace
MessageChannel::Financialwith an explicit accounting-carrier capability, and clarify that B1 ledger taps create financial intel without scheduling a social message. - Real fifth message channel. Add Financial to the messages channel table, define its read condition, and route invoices/pay stubs/accounting records through actual scheduled
Messageinstances. - Keep the overloaded enum. Continue using
MessageChannel::Financialonly as a device capability tag, document that exception, and leave its unused delivery/read branch in place. - Something else (say what).
Why this is open #
wiki/mechanics/messages.md binds exactly four delivery channels: Email, Phone, InPerson, and Filing. Runtime also defines MessageChannel::Financial and gives it unconditional person-read behavior, but no current Message, authored traffic pattern, or plot beat uses that channel. Instead, the switch advertises it as a device capability; tap_accounting and device TAP use the tag to create RawIntelKind::FinancialFlow directly.
The flow law and wiki/mechanics/economy.md separately assign money to the account graph (AccountGraph / FlowChannel). Economy history shows that the enum reuse was intentional B1 scaffolding, so this is not safely reducible to a missing table row: either the type leaks across graph boundaries or the corpus omits a real channel whose behavior has never been implemented.
Options #
| Option | Trade-off |
|---|---|
| 1. Separate carrier capability | Matches the three-graph flow law and live behavior; requires a small type split across reach, actions, Operations projection, and economy tests. |
| 2. Real Financial messages | Makes invoices and pay stubs literal interceptable traffic; adds new delivery/read semantics and rewires working economy discovery through the message scheduler. |
| 3. Document the overload | Smallest change; preserves a dead read-condition branch and keeps message_channels semantically dishonest. |
Recommendation #
Choose 1: separate account-graph carrier. Every live financial path already belongs to the account graph, while MessageChannel::Financial is only a marker saying that a device carries the books. Splitting that capability preserves the flow law without inventing an unused fifth social channel.
What your answer unlocks #
The next tick can amend wiki/mechanics/messages.md, wiki/mechanics/economy.md, and the relevant reach contract, then either split the carrier type (option 1), implement scheduled Financial traffic (option 2), or document the explicit exception (option 3). The queued contradiction can then be removed and this issue closed.