Techniques
Programmatic verification — scopes and diagnostic results
The independent verifier and shared runtime allow a host to inspect source, references and profile rules without granting editing through a viewer.
Why use it?
Scripts and CI need answers, not pictures: which verb may connect these kinds, which diagnostics fired and where, and whether the page survives print rules — all without opening a tool.
When it helps
Authoring assistance (verbs), CI gates (--diagnostics json, --strict-print), documentation pipelines (publish) and quick previews (--content-size).
How to read it
- Choose the verification scope and supply the complete source set.
- Inspect diagnostics, completeness and unsupported capabilities explicitly.
- Keep loading, verification, editing and exporting as distinct host responsibilities.
What you need
- The entry file and included source files
- The installed profile pack
- The requested scope and completion level
Things to check
- The deprecated prototype CLI commands are not the new utility API.
- A successful source parse alone does not establish semantic completeness.
Use the current module APIs. Automated deployment, arbitrary code execution and external process enforcement are outside this example.
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.