> For the complete documentation index, see [llms.txt](https://dev.guardian.hedera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev.guardian.hedera.com/guardian/workspace/schemas/schema-editor.md).

# Schema Editor

The Schema Editor is the visual workspace in which a Standard Registry builds and maintains a schema: its fields, its sub-schema references, its conditional logic, and its metadata. It is the authoring surface for everything a schema defines before that schema is saved, versioned, and published.

#### The problem it solves

A schema is a JSON Schema document. Authoring one by hand means writing property definitions, `required` arrays, `$ref` pointers, `if/then/else` blocks, and Guardian-specific field metadata such as units, GeoJSON types, and updatability flags – all in a format where a single misplaced key produces a schema that validates nothing, or validates the wrong thing.

The Schema Editor removes the JSON layer from routine authoring. Fields are added, configured, reordered, and linked through the interface, and the document a submitter will eventually fill in can be previewed at any point during editing.

#### How it works

Think of the editor as three coordinated panels around a single schema under edit.

**The left panel is the source of new material.** It carries two lists: the field-type palette, grouped into simple types, geographic types, units of measure, and Hedera types; and the list of existing schemas in the same topic, which can be referenced as sub-schemas. Items move from this panel onto the canvas.

**The canvas is the schema itself.** It shows the schema's fields in order, each carrying badges for its state – required, optional, array, hidden, updatable, auto-calculate. System fields, which Guardian supplies and the author cannot remove, are shown separately from the fields the author owns. The canvas has three views of the same schema: **Fields** for structure, **Conditions** for `if/then/else` logic, and **Links** for repeatable field links between arrays.

**The right panel configures whatever is selected.** With a field selected it exposes that field's title, key, type, pattern, unit, required and visibility rules, enum values, and default, suggested, and test values. With nothing selected it exposes the schema's own properties: name, description, and entity type.

Two further ideas explain most of the editor's behaviour.

**Drilling.** A referenced sub-schema is not flattened into its parent. Opening one pushes it onto a drill stack, and the canvas then shows that sub-schema's own fields and conditions. This is why conditions that span two sub-schemas are defined on the parent that references both – the parent is the only level at which both are visible.

**Preview.** The **Preview** tab renders the live form generated by the current draft, in either the submitter's view or the read-only view a reviewer sees. Preview reflects unsaved state, so structural and conditional mistakes surface during authoring rather than during a policy run.

Work in the editor is a draft until saved, and the header reports whether changes are outstanding. Saving does not publish. Publishing is a separate, deliberate step that fixes the schema's version and writes it to Hedera; after that the schema becomes read-only, and further change means creating a new version.

#### Key distinctions

**Schema Editor and Schema Tree.** The editor changes one schema and the sub-schemas it references. The Schema Tree is a read-only visualisation of how schemas relate across a policy. Use the tree to understand a structure, the editor to change it.

**Saving and publishing.** A saved schema is a draft: local, mutable, and invisible to policies. A published schema is immutable and on-chain. The editor allows free change up to the moment of publication and none after it.

**Editing and importing.** The editor authors a schema in place. Import brings an existing definition in from Excel, a `.zip` file, or IPFS. Imported schemas open in the editor as drafts, so the two are sequential steps rather than alternatives.

#### Related

* Task: [Creating a Schema](/guardian/workspace/schemas/creating-system-schema-using-ui.md)
* Task: [Importing a Schema](/guardian/workspace/schemas/importing-schema-using-ui.md)
* Reference: [Available Schema Data Types](/guardian/workspace/schemas/available-schema-types.md)
* Concept: [Schemas](/guardian/workspace/schemas.md)
* Concept: [Cross-Schema Conditions](/guardian/workspace/schemas/cross-schema-conditions.md)
* Concept: [Schema Tree](/guardian/workspace/schemas/schema-tree.md)