Techniques
Markings and metadata — claims with explicit meaning
Annotations, status and provenance carry distinct design claims. They must be read with their property and profile contracts.
Why use it?
"This path must not exist" and "this box is a draft" are design facts; keeping them in the model means they export, diff and render under every theme — instead of living in someone's slide notes.
When it helps
Migration plans (forbidden legacy paths), drafts under review (tentative scope), machine-generated documents (generator provenance), and audit claims (assertions).
How to read it
- Separate lifecycle status from drawing style and from other semantic annotations.
- An assertion needs evidence when its contract requires evidence.
- A successful render does not make a claim true or accept the design.
What you need
- The claim being recorded
- Its owner and applicable metadata contract
- Any required evidence or provenance
Things to check
- A visual marker alone is not an authorization or acceptance record.
- Do not use annotations to erase an inconvenient dependency.
Verification checks declared contracts and supplied information; it cannot establish facts about an unobserved external system.
Work with the converted example
- Open the viewer and select
main. 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.