State before surface
A product should make the current state, the next possible action, and the consequence of that action legible before visual polish carries the story.
HAAM product edition
the product namespace
Eight products. Each starts with an interaction contract.
The spec comes before the implementation: what a person is trying to resolve, which states the system must expose, where automation has to stop, how failure behaves, and what evidence would prove the interaction is finished. The live builds can work backward from that.
Interaction grammar
Behavior before screenshots.
A product should make the current state, the next possible action, and the consequence of that action legible before visual polish carries the story.
A recommendation, score, classification, or answer should keep the source material close enough that a person can inspect why the system believes it.
The interface must distinguish sensed, inferred, suggested, confirmed, and executed states instead of letting automation blur them together.
The more consequential an action becomes, the clearer the confirmation, preview, scope, and recovery path must be.
Unknown, stale, unavailable, and unsupported are designed states. The system should not quietly fill gaps with confidence it does not have.
Every important flow needs an interruption, refusal, correction, undo, retry, or handoff path that preserves what the person already did.
On haam.co
Open a case study for the target state model, edge cases, definition of done, and the receipts the current build can already show.

01
When someone writes, the answer should already be in the work. Approved knowledge, three confirmed actions, then the rest comes to me with the context attached.
Answer from approved evidence. Ask before acting. Escalate without making the client start over.

02
Cash arriving and leaving, so I can see whether the work is covering the life around it. The public host shows a demo set.
Every financial conclusion must open back into the rows that made it true.

03
Held still so the material, the light, and the construction can be looked at.
Manipulate one object directly, then share the exact view rather than a generic product page.

04
Sleep, energy, time, and what already happened this week decide the session. Then you can see why. The web host uses demo data.
Turn today’s constraints into a readable fitness suggestion, with the reasons and the stop condition visible.

05
A signal can suggest. You still say whether it happened.
A device may notice a signal. Only the person can say the routine actually happened.

06
Personal Atmotube PM2.5 next to the CAMS city background, hour by hour.
Compare personal exposure with the city only when metric, place, and hour actually line up.

07
Find open calls, rank them against the evidence and talk ideas, prepare the pack, send only with approval.
Reduce a pile of open calls to a grounded shortlist, then keep sending behind a human decision.

08
The closest managed swim places, the official baseline, nearby pollution, and what the city can still do. Check today’s local notice before you enter the water.
Show what is officially known about a swim spot, how old it is, and where to verify today.
A job that needs its own address?
Optional analytics. Google Analytics and Clarity load only if allowed; form, email, and chat content are excluded.