Data structures and meaning
Whiteboard / discovery sketch
A preliminary map of named concepts and their relationships. An unspecified object deliberately leaves storage technology and detailed structure undecided; it is not an undocumented SQL table.
Why use it?
Use this to expose disagreements about vocabulary before implementation choices obscure them. A shared sketch provides stable identities that can acquire fields, domains and deployment details later.
When it helps
Start an unfamiliar project or facilitate a meeting where participants need to agree on the important things before they agree on keys and types.
How to read it
- Read the nouns in the boxes first.
- Read each connecting verb as an assertion, not as an enforced foreign key.
- An unselected element is out of scope for this sketch, not deleted from the model.
What you need
- Names understood by the participants
- Relationship meanings and direction
- Questions that have not been settled
Things to check
- Do not infer a table from every rectangle.
- Do not treat proximity, colour, or a crossed line as a new fact.
This is an explanatory model, not an executed business system. A successful render does not establish implementation effectiveness or independent approval.
Work with the converted example
- Open the viewer and select
diagram. Inspect the rendered view and its source. - Open the designer. Keep the selected profile and inspect its legal palette and property controls.
- Change one displayed title or an appropriate data value. Apply the edit and check the resulting diagram.
- Run the verifier and review its diagnostics before moving complete content into review.
- Download your edited DDN source to retain the change.
The example uses the indentation-based ddn-next-1 dialect. The language guide explains reusable definitions, dotted data rows and explicit property blocks.