Getting started

Describe an object

This is the point of the whole tool. The schema already says what columns exist and what type they are — a diagram can show that. What it cannot show is what only lives in people’s heads: why this table exists, what a status code means, what breaks if you touch it. Write that down for the person who arrives after you, and the flow becomes documentation instead of decoration.

Select a node and open the inspector. Each field captures a different kind of knowledge — use the ones that carry real meaning, and leave the rest empty rather than padding them.

1. Description (General tab) — what this object is and why it exists.

   Answer the question a newcomer actually asks: "what is this for?" — not "what columns does it have", which they can already see.

2. Business logic (Logic tab) — the rules the schema can’t show: what a status code means, the order things run in, what a procedure really does.

   This is the knowledge that leaves when a person leaves. Writing it down is the difference between a two-day handover and a two-minute read.

3. Gotchas (Logic tab) — the watch-outs and deliberate weirdness. The column that isn’t what its name suggests; the thing not to do.

   A gotcha read *before* someone trusts a field prevents the bug they would otherwise ship.

4. Column Description and Compliance Tag (Schema tab) — describe individual columns and mark sensitive ones.

5. Write for a stranger, not for yourself. Short, concrete, specific.

   Everything you write also travels into the flow’s exports — so good notes serve the next teammate and the AI they paste it into equally.