A normal financial interface optimizes for quantities: price, balance, cost basis, yield, and change. Rumio needs those facts, but they are not the final experience. The project asks what happens when financial state becomes spatial memory.
The simple version would map each ticker directly to a piece of furniture. That is easy to understand and quickly becomes arbitrary. Rumio instead needs a small rendering grammar that describes what a position contributes to the room.
The room is not a metaphor painted over the ledger. It is another way to read the ledger.
A rendering grammar
Each supported asset may contribute properties rather than a fixed object: energy, structure, computation, communication, shelter, or reserve. The renderer combines those properties with verified balance thresholds and the room's existing state.
Enough energy may illuminate an existing lamp before it creates a new one. Computation may first activate the terminal, then expand the desk. A diversified position may strengthen a wall rather than place a branded object in the room. The mappings should be published and versioned so that the visual result can be reproduced independently.
State, history, and memory
Current balances answer what Rumio holds now. Transaction history answers how it arrived there. Policy events answer what it attempted and what the house rejected. These are different sources and should create different visual effects.
A current position can create a solid object. A disposed position may leave a faint outline or an entry in the room archive. A rejected action should not create property, but it may leave a short line in the decision record. The interface must never confuse intention with execution.
Price is weather
Price movement should affect atmosphere, not encourage constant performance checking. Volatility may produce rain against the window. A quiet market may make the room still. Large changes may alter light or sound without moving the furniture itself.
This distinction keeps the room from turning into a casino display. Assets determine what exists. Market conditions determine the weather around those things. Rumio's objective is legibility and continuity, not a green number at the end of every day.
Proof beside poetry
Every object needs an inspection view showing the source contract, relevant balance, mapping rule, block number, and renderer version. The poetic layer can say that a lamp appeared. The technical layer must make it possible to verify why.
The current ASCII room is only a design preview. It contains no claim that Rumio owns the lamp, desk, or reserve shown there. When real data arrives, verified objects will be visually distinct from plans, memories, and hypothetical designs.