Inspector pane

The inspector pane on the right side of the playground shows the complete metadata for whatever you've selected in the diagram. It's the place to look when you want to know exactly what the parser made of a specific construct, beyond what fits on a diagram card.

📸 Screenshot placeholder

[Screenshot needed] Filename suggestion: inspector-pane-field.png Caption: The inspector showing a selected field with its identification, type, flag badges, settings, and Note. Should show: the playground with a field selected in the diagram (the row visibly highlighted), and the inspector pane open on the right showing: kind badge (FIELD), field name, parent entity and container, type, REQUIRED and UNIQUE badges, a couple of settings rows, and a Note block with some text.

When it appears

The inspector slides in from the right when you select something in the diagram. Five kinds of things are selectable:

• Containers (Schema, Database, Keyspace, etc.)
• Entities (Table, Entity, Collection, Record)
• Fields (any field row, at any nesting depth)
• Relationships (Ref: declaration lines)
• Supertype groups (the half-circle symbols; see Supertype groups)
• The diagram on display, by clicking an empty area of the canvas: the Project on Main ERD, or the diagram view shown (see Diagram views)

Selecting anything opens the inspector if it was closed.

How to close it

Two ways:

• Click the × button on the inspector header. The inspector is hidden and the selection is cleared.

A click on an empty area of the canvas does not close it: it shows the diagram on display, as described below.

Once closed manually, the inspector stays hidden until you make a new selection. Your "explicitly closed" state persists across reloads, so if you prefer working without the inspector you don't have to dismiss it every session.

What's in each kind of inspector

The header always shows a colored badge with the kind (SCHEMA, TABLE, FIELD, REF, SUPERTYPE GROUP, STICKY NOTE, DEP, DIAGRAM, DIAGRAM VIEW) and the element's name. Below that, the body is organized into labeled sections that vary by kind.

Container inspector shows:

• Identification: keyword (Container / Schema / Database / etc.), name, member count
• Settings: target engine, type, and any other settings on the container declaration
• Note: the container's Note: '...' body if present

Entity inspector shows:

• Identification: keyword (Table / Entity / Collection / etc.), name, parent container (if any), field stats (total / primary keys / required / nested)
• Constraints, when the entity has any: its primary key, its unique keys and its checks, each with its constraint name when it has one. Keys and checks appear here however the schema declares them: in a constraints { } block, inline as [pk] or [unique], as a DBML pk entry in indexes, in a checks { } block, or as a field's check: setting. A key declared outside the constraints block is labeled with its form, such as "inline" or "indexes (DBML form)"
• Supertype groups, when the entity takes part in one: as a supertype, each group it anchors with that group's subtypes; as a subtype, its group and its supertype; an entity that is both shows both
• Internal definitions, when the entity declares a definitions { } block (spec §15.8): each name, with the field count of an object-shaped definition or the base type of a scalar one
• Settings: any settings on the entity declaration
• Note: the entity's Note: '...' body if present
• Source query, for a View: the first source_query: of its body, highlighted as SQL
• Loaded by, for the target of a source-to-target mapping: the Deps that load it, and the fields no dependency feeds; for a View that is not materialized, Metrics: each metric with the fields it aggregates

Field inspector shows:

• Identification: name, dotted path within the entity, parent entity, parent container
• Type: short label plus an expandable structural breakdown for compound types (objects, arrays, oneOf, etc.)
• Flags: badges for PRIMARY KEY, UNIQUE, REQUIRED, and AUTO-INCREMENT when present
• Settings: regular settings (default values, regex patterns, length constraints, etc.)
• Custom properties: anything starting with x_, or with x- in a quoted key such as "x-hackolade-id", shown in a separate section, since these are the AI-readiness extension point
• Note: the field's Note: '...' body if present

Relationship inspector shows:

• Identification: operator (> < - <>, with its ? marks when written), source and target (a field path, or an entity for a conceptual relationship), the name if the Ref was declared with one, the type (foreign key or foreign master), the reading direction (source to target, target to source, both ways, or not stated), and the constraint type (identifying or non-identifying) when stated
• Cardinality: the range of each end and what states it: a source: or target: setting, the operator, a ? mark, or a nullable foreign key. A note explains which applies when a mark and a setting disagree. See Relationships & crow's foot notation
• Reading, when any is written: the roles and verbs of each end and the cardinalities, read back as sentences
• Settings: any other settings on the Ref declaration

Sticky note inspector shows:

• Identification: the note's name, its Container when it has one, and its color, or "Default"
• Custom properties, when the note has any
• Text: the note's Markdown, rendered
• See Sticky notes

Dep inspector shows:

• Identification: the Dep's name when it has one, its form (short, block, or inline on an entity, a View or a field), its color, and the language of its statement when it names one
• Dependencies: each read back as a sentence that names the elements, such as "fct_orders.revenue is computed from stg_orders.amount", with the note and settings of a dependency that carries its own
• Source-to-target mapping, instead of the sentences, when the dependencies carry kinds of transformation: one row per target field with its sources and its kind, then the lines that steer the rows, such as a lookup or a filter
• Transformation: the note of the Dep, rendered as Markdown
• Source query: the statement of the Dep, highlighted as SQL, when it has one
• Custom properties, when the Dep has any
• See Data lineage

Supertype group inspector shows:

• Identification: the group name, the supertype, completeness and exclusivity ("Unstated" when absent), and a sentence reading them back, such as "Every Party is exactly one of: Person, Organization."
• Subtypes: each subtype with its own strategy, or "follows the group"
• Materialization: strategy, merge and discriminator, the intent for a later physical derivation
• Settings: custom or unrecognized settings
• Note: the group's note if present

Diagram inspector, opened by a click on an empty area of the canvas, shows the diagram on display:

• On Main ERD: the Project's name and targets ("None declared" without a Project); counts of the entities, database views, Containers, relationships and Edges of the model; the names of its diagram views; and the Project's note
• On a diagram view: its members, with the Containers framed around them; its categories as written; its custom properties; and its note (see Diagram views)
• Switching the Diagram menu while this pane is open shows the diagram you switch to

A setting or a note that a Metadata block sets (spec §24.7) shows among the element's own, with a small Metadata badge. See Metadata blocks.

Links between panes

Names shown as links in the entity and supertype group inspectors select what they name: click a group to open its pane, or a supertype or subtype to open that entity's pane. The diagram selection moves with it, so the highlighted element always matches the pane.

Read-only

The inspector is purely a display surface in this version. You can't edit values in it; click the Edit in source button at the bottom of each inspector to jump your editor cursor to the right place and edit by typing. The "single source of truth" is always the text in the editor; the inspector is a view onto it.

Edit in source

Every inspector has an Edit in source button at the bottom. Clicking it moves the editor cursor to the start of the inspected element in the source code, scrolls the editor to that position, and gives the editor focus. Useful when:

• You've found something interesting in the inspector and want to make a change
• A field is buried deep in nested structure and you don't want to scroll through the editor to find it
• You're following a relationship from one entity to another and want to inspect the declaration

The button works on every inspector kind: on the diagram, it goes to the Project declaration or to the diagram view.

Resizing the pane

Drag the vertical divider on the left edge of the inspector to resize it. The width range is 240 to 600 pixels. Width is remembered across reloads.

The inspector takes priority over the diagram pane: as the inspector widens, the diagram narrows. The editor pane's width is not affected.

Persistence

Three things about the inspector are saved to local storage:

• The current selection. If you select an entity, reload the page, the same entity is selected and the inspector opens to it (provided that entity still exists in the schema).
• Inspector width. Restored on reload.
• The explicit-close flag. If you dismissed the inspector via the × button, it stays dismissed across reloads until you click something in the diagram.

If the schema is edited such that the persisted selection no longer matches anything (the named entity was deleted, the path no longer exists), the inspector silently shows its empty state on next load and waits for a new selection.

What's next

• Reading the diagram: the visual vocabulary that the inspector adds detail to.
• Diagram pane: how to select things in the diagram.
• Editor pane: where edits actually happen, after Edit in source navigates you there.