Models and generated artifacts

Once a model is resolved, a consumer can navigate it, serialize it, or generate another artifact from it. Choose the representation according to what the consumer needs to retain.

Representation	Useful for
JSON	Inspecting the model and supplying data to templates or other applications
SQLite	Querying a relational projection of definitions and their relationships
Live	Navigating the native graph with real links, metadata, and external-value handling
Mustache rendering	Turning the JSON presentation into a text artifact

Serialization is a presentation of the model. Its representation choices are not additional language rules for references or composition.

A catalog to generate from

Save these complete inputs in a new folder:

Catalog.nxscript

Catalog Shop {
    Title: "Corner Stationery";
    Product Notebook { Title: "Pocket notebook"; PriceCents: 450; }
    Product Pencil { Title: "Graphite pencil"; PriceCents: 90; }
}

Catalog.mustache

{{#Shop}}
{{Title}}
{{/Shop}}
{{#_nx.Collections.Product}}
{{Title}}: {{PriceCents}} cents
{{/_nx.Collections.Product}}

Run:

NexusScript /input=Catalog.nxscript /output=Catalog.json
NexusScript /input=Catalog.nxscript /template=Catalog.mustache /output=Catalog.txt

The generated text is:

Corner Stationery
Pocket notebook: 450 cents
Graphite pencil: 90 cents

Inspecting Catalog.json makes the template's paths understandable. Shop is a root keyed by its definition name. _nx.Collections.Product is the collection of contributed Product definitions, including those nested under Shop.

Metadata and collections

Every definition's _nx metadata identifies its kind, name, source range, and reference status. Target clauses are retained where present. The top-level metadata contains the compilation time and collections by actual definition kind. Metadata belongs to the representation; your domain properties remain ordinary members beside it.

Name is a valid domain property and is distinct from _nx.Name. _nx itself is reserved by the JSON representation. Do not use it as a domain property or child name when emitting JSON.

Collections gather authored contributions from the entry document and its includes. A module-only reusable base does not contribute independently merely because another definition composes from it. References do not create extra declarations in collections. No kind is automatically pluralized.

Scalar values serialize as JSON strings. Arrays retain their order. An unnamed scalar array entry is a string; a named scalar or nested-array entry has _nx.Name plus Value. Definition entries retain their normal definition shape.

References in JSON

A reference to a definition emits a bounded view of its target. That view contains scalar properties, scalar-only arrays, and ordinary children. Arrays containing definitions or definition references are omitted from the reference view, including nested or mixed structural arrays. The original definition and the Live graph retain those arrays.

Use a qualified reference to a specific value when that is what a consumer needs:

Projection.nxscript

Catalog Shop {
    Product Notebook {
        Title: "Pocket notebook";
        Variants: [Variant Small { Pages: 80; }];
    }
    Featured: @Notebook;
    FeaturedPages: @Notebook.Variants.Small.Pages;
}

Featured's JSON projection omits Variants; FeaturedPages is "80". Shop.Notebook still contains its authored Variants array. This is an emitter choice, not a missing reference in the language model.

Concrete definitions may have self/mutual links. If JSON would expand those links recursively, emission reports a recursive-projection error. Independent references to the same target are not themselves a cycle.

SQLite

NexusScript /input=Catalog.nxscript /format=sqlite /output=Catalog.sqlite

Use the SQLite runtime supplied with the matching Nexus release; an older system library may not satisfy the binding's version requirement. The emitter creates relational tables from the consumer-visible definitions. In this example Shop, Notebook, and Pencil are table names: definition names, not automatic pluralizations of kinds. Property-contained definitions and array tables use their property names.

Rows have an emitter-owned nx_id; ownership links identify the actual owner table. Arrays preserve order. Definition-valued reference properties become <PropertyName>_id foreign keys to existing target rows. The target must belong to the output; a module-only target is not silently added.

A dialect supplies the permitted shapes when present. Without one, the emitter discovers shapes from completed values; an empty array supplies no shape and therefore no dialectless table. References in array entries are not covered by the property-reference foreign-key projection.

Writing an existing database replaces the projected tables in a transaction and leaves unrelated tables intact. Keep generated data separate from application-owned data unless that replacement is intended.

Live

Live is a native in-memory graph, not a CLI stream format. It retains shared reference targets, full structural arrays, source/contributor information, and deferred external expressions. It owns its graph independently of the compilation session that produced it.

A consumer can supply external read handlers, read values, or pass Live to the JSON renderer with those handlers attached. Ordinary compiled-document emitters require materialized values and reject unresolved external expressions and external assignments. Serialization does not invent an external-state policy.

See Embedding for a complete native consumer. Continue with Manifests and tabular data.