Data entity detail page

The data entity detail page — composition of the Overview tab, class-driven panel matrix, badges, sidebar list truncation, and per-panel permission map. Where every catalog discovery lands.

Clicking a data entity in Search, in the Directory, in a Catalog Overview tile, in a lineage node, or in the Activity feed lands the user on the same per-entity detail page. The Overview tab is the default landing surface — a single composed page showing everything the catalog knows about the entity, with edit affordances gated by per-panel permissions and per-class composition rules.

This page is the canonical reference for the detail-page composition itself. For the aspect-level deep dives — authoring the Markdown description, curating custom metadata, annotating individual columns on a dataset's Structure tab, applying tags, curating business names, wiring statuses, attaching files, reading the stale indicator, and grouping into Data Entity Groups — follow the per-aspect pages cross-linked below.

Overview tab composition

The Overview tab renders a two-column grid for every catalogued entity:

• Main column (left) — class-driven stats, Description, Attachments, Metadata, optional Expectations, optional Metrics.

• Sidebar (right) — General identity + Owners, optional Data Quality panels, Groups, Tags, Terms.

Twelve sub-panels combine on the surface:

Panel	Column	What it shows	Aspect page
Class-driven stats	Main	A class-specific summary block — dataset structure card, transformer source/target list, consumer input list, quality-test datasets, data-input output list, relationship endpoints, or entity-group member set, depending on the entity's class.	Main Concepts → Data Entity Class
Description	Main	The entity's human-readable Markdown description, with linked terms inline.	Entity description; Business Glossary for the inline term-link surface.
Attachments	Main	Files and remote-URL attachments uploaded for the entity.	Data Entity Attachments
Metadata	Main	Custom (operator-curated) and predefined (collector-ingested) metadata fields in one combined list.	Custom metadata
Expectations	Main (conditional)	Renders only when the entity has quality-test expectations — parameters and linked URLs from the test definition.	Test Results Import
Metrics	Main (conditional)	Renders only for datasets — column-level stats and metrics.	—
General	Sidebar	Namespace, datasource link, source-side timestamps, view count (see the view count caveats below), ODDRN, and the Owners list.	Authorization → Owners
DQ SLA report	Sidebar (conditional)	Renders only for datasets with at least one quality-test report; shows the SLA roll-up.	Quality Dashboard
DQ test report	Sidebar (conditional)	Renders alongside the SLA report; shows the latest passed / failed / aborted totals.	Quality Dashboard
Groups	Sidebar	Data entity groups this entity belongs to.	Data Entity Groups & Domains
Tags	Sidebar	Tags applied to the entity.	Manual Object Tagging
Terms	Sidebar	Linked business-glossary terms.	Business Glossary

The page header above the tabs shows the entity name, the class badges, the type badge, the stale indicator, the status, and (where applicable) the "Edit business name" / "Edit group" / "Share" buttons. Header affordances follow the same per-class and per-permission rules as the Overview composition; see Class and type badges below.

Below the Overview tab, additional class-driven tabs appear — Structure (datasets only; see Per-column annotation for the column-level composer that lives on this tab), Lineage (most classes; see Data Lineage), Test reports and History (quality tests, transformer runs), Linked entities (per-class linkage), Discussions (when Data Collaboration is enabled), and Activity (the per-entity Activity feed audit trail). Which tabs appear depends on the entity's class set; the next section names the mapping.

General panel — view count caveats

The General panel's view count is the running total of times this entity's detail page has been fetched. Two behaviours are worth knowing before you read or rely on the number.

Opening a detail page registers as +2, not +1. Each page-open fetches the entity detail twice, and each fetch bumps the view count by one — so a single visit adds 2 to the number, not 1. The count therefore overstates real visits by roughly a factor of two. Read it as a relative popularity hint, not an exact visit tally.

View count is the sole signal behind the home-page Popular ranking, and it is trivially inflatable. The Catalog Overview → Popular column ranks entities by view count alone, highest first. View count is bumped on every detail-page fetch with no rate limit, no per-user de-duplication, and no authentication required, and on a deployment with authentication disabled (auth.type=DISABLED) both the detail-page read and the GET /api/dataentities/popular endpoint are reachable by any caller on the network. A short scripted read loop can therefore push any chosen entity to the top of the Popular column. Do not treat the view count or the Popular ranking as trustworthy usage evidence in audits or capacity decisions; cross-check against your own access logs.

Per-class panel matrix

The set of panels and tabs visible on a detail page depends on the entity's class — the categorical taxonomy that drives every composition decision. A single entity can carry multiple classes (e.g. an ML training pipeline that is both TRANSFORMER and ENTITY_GROUP); each class contributes its own panels.

Class	Main-column stats panel	Tabs beyond Overview
SET (Dataset)	Dataset structure card — column count, row count, source-side schema link.	Structure, Lineage, Test reports, History (when test runs exist), Linked entities, Discussions, Activity.
TRANSFORMER (Job / Pipeline)	Sources and targets list, with unknown-source / unknown-target counts surfaced separately.	Lineage, History, Linked entities, Discussions, Activity.
TRANSFORMER_RUN (Job run)	No main-column stats panel renders today — the parent transformer's panel does not propagate to its runs. Per-run details live in History.	Lineage, History (own row), Linked entities, Discussions, Activity.
CONSUMER (Microservice / BI tool)	Input list and unknown-input count.	Lineage, Linked entities, Discussions, Activity.
INPUT (Source data feed)	Output list and unknown-output count.	Lineage, Linked entities, Discussions, Activity.
QUALITY_TEST	Suite name, suite URL, tested datasets, test parameters.	Test reports, History, Linked entities, Discussions, Activity.
QUALITY_TEST_RUN	No main-column stats panel renders today — the parent quality test's panel does not propagate to its runs. Per-run reports live in History.	History, Linked entities, Discussions, Activity.
ENTITY_GROUP (DEG)	Member list and the entity-group authoring affordances.	Group Lineage, Linked entities, Discussions, Activity.
RELATIONSHIP (ERD)	Source / target endpoints, cardinality, and join semantics.	Linked entities, Discussions, Activity.

For the canonical class taxonomy and how collectors assign classes during ingestion, see Main Concepts → Data Entity Class.

An entity may render no main-column stats panel — silently — for two distinct reasons. First, if the entity's class array is empty, undefined, or contains a value the UI does not recognise. Second, if the entity is one of the run classes (TRANSFORMER_RUN or QUALITY_TEST_RUN) — both are recognised enum values but the panel switch has no case for them, so they fall through to the default no-render branch. In either case the rest of the Overview (Description, Attachments, Metadata, sidebar panels) still loads, but the class-specific summary block is absent with no visible placeholder. When an Overview is missing its expected stats panel, first check the per-class matrix above (run-classes are expected to be empty here); if the class is none of the run-classes, check the entity's class assignment at the collector — that is the most likely cause.

The right-column Data Quality section is hidden when a dataset has zero test reports — and when the report is still loading. The DQ panels appear only when the entity is a dataset AND its test-report total is non-zero. A dataset with no quality tests configured renders no DQ section. A dataset whose test-report fetch is still in flight also renders no DQ section. Both states produce the same empty space in the sidebar; the only way to tell them apart today is to wait and re-check, or to inspect the network tab. Treat sidebar DQ absence as "no tests or still loading" rather than as a confirmed "this dataset has no quality coverage" signal.

Class and type badges

The detail-page header renders the entity's class taxonomy as a row of badges next to the name:

• Class badges — one chip per entry in the entity's class array. Each chip is colour-coded per class (palette resolved from the platform's UI theme — the colour identifies the class at a glance once you've learned the mapping). Hovering a badge surfaces the canonical class label (the short label is on the chip; the longer "normal" label is in the tooltip).

• Type badge — one chip immediately to the right of the class badges, showing the entity's specific type (TABLE, VIEW, JOB, DASHBOARD, ML_MODEL_TRAINING, etc.). The type label is the formatter-stripped underscore-free upper-case form of the underlying enum value.

Class is the load-bearing taxonomy; type is descriptive. The class array drives every per-class composition decision on the page — which stats panel renders, which tabs are visible, whether the DQ sidebar appears. The type is a finer-grained descriptive label collectors set alongside the class; it does not gate UI surfaces today.

A few operator-visible behaviours of the badge row to be aware of:

• No tooltip explains per-class consequences. A badge names the class (e.g. Dataset, Transformer) but does not say "this class is why you see a Structure tab" or "this class is why this entity has source/target panels." The mapping is in Per-class panel matrix above; the header surface does not surface it directly.

• The type badge is not colour-coded. Class badges use per-class colours; the type badge uses a uniform background regardless of type. A dense list (search results, directory list) is therefore class-coloured but type-uniform — operators scanning a list distinguish entities by class colour at a glance, by type only after reading the label.

• An entity with no recognised class renders no class badge — silently. Combined with the matching stats-panel absence noted above, an unclassified entity is structurally indistinguishable from an entity whose class payload was lost in transit. If the badge row shows only a type badge and no class chips, treat the entity as ingestion-incomplete and check the collector.

• Multi-class entities overflow horizontally. The badge row uses no-wrap layout, so an entity carrying four or more classes overflows the horizontal allocation rather than wrapping to a second line. In practice multi-class entities are uncommon; an ML model that is both ENTITY_GROUP and TRANSFORMER is the canonical case. The "Edit business name" button shares the same row, so heavy class overflow can compress the visible name.

• The DCT type is a deliberate special case. The type-name slot accepts the standard collector enum plus the literal string 'DCT' — the dbt-cloud type, surfaced on the badge alongside the collector-side enum. If you see a DCT type on a TRANSFORMER-class entity, that is the odd-dbt push-adapter ingestion chain.

Sidebar list truncation (Tags / Terms / Groups)

The sidebar's Tags, Terms, and Groups panels cap visible items to keep the surface from stretching vertically. The cap is panel-specific and a View All (N) toggle expands the full list inline:

Panel	Initial visible	Toggle
Tags	First 20 tags	View All (N) button at the panel foot when the list exceeds 20.
Terms	First 20 linked terms	Same.
Groups	First 10 group memberships	Same.

The toggle's count suffix is the only visual signal that the panel has been truncated. An entity with exactly 20 tags shows a button-less footer; a 21-tag entity shows View All (21).

Tags ordering is not importance-stable across the truncation cap. The Tags panel sorts by importance (important tags first) then alphabetically — but the sort runs after the cut to the first 20. An entity carrying more than 20 tags whose important ones happen to sit beyond the first 20 in collector-insertion order (for example: an operator tagged the entity once early, then added the important tags later) sees the visible window in raw insertion order, with the important tags missing from view; the user must click View All to find them. Mitigation: when you mark a tag important and expect it on the entity's at-a-glance strip, verify by opening the full list until the upstream fix lands.

The Groups and Terms panels' visible-window ordering is undefined. Both panels apply a default sort with no comparator, which JavaScript resolves by stringifying each entry — yielding the same string for every object and leaving the order effectively as-received from the server. The Groups list (DataEntityRef[]) and the Terms list (LinkedTerm[]) share the same stringification defect. Display order in the visible 10 (Groups) or visible 20 (Terms) is collector-insertion order; do not rely on it being alphabetical or importance-based.

Within the visible window the truncation hint is the View All (N) button label only — visible items themselves do not fade or show a +N more tile to signal overflow before the click.

Permissions surface

Every editable panel on the Overview tab evaluates its own permission set locally. The detail page does not declare a single "what can I edit on this entity?" permission map — each panel is gated independently.

Panel	Permissions evaluated for edit affordance
Description	DATA_ENTITY_DESCRIPTION_UPDATE
Attachments	DATA_ENTITY_ATTACHMENT_MANAGE
Metadata (custom)	DATA_ENTITY_CUSTOM_METADATA_CREATE, …_UPDATE, …_DELETE
General — Owners	DATA_ENTITY_OWNERSHIP_CREATE, …_UPDATE, …_DELETE
Groups	DATA_ENTITY_ADD_TO_GROUP, DATA_ENTITY_DELETE_FROM_GROUP
Tags	DATA_ENTITY_TAGS_UPDATE
Terms	DATA_ENTITY_ADD_TERM, DATA_ENTITY_DELETE_TERM

The page header carries its own per-affordance permission gates:

Header affordance	Permission
Business name (Add / Edit)	DATA_ENTITY_INTERNAL_NAME_UPDATE
Status change	DATA_ENTITY_STATUS_UPDATE
Data Entity Group edit (manually-created groups only)	DATA_ENTITY_GROUP_UPDATE
Share to Slack	No separate permission — gated only by the DATA_COLLABORATION feature toggle.

When auditing "what does role X see on this entity," cross-reference each row of the two tables above against the role's permissions via Permissions. The detail page does not surface the role-to-affordance map in the UI; the audit lives in the role definitions.

When the entity's status is DELETED, several Overview-tab and header edit affordances are hidden regardless of the operator's permissions — soft-deleted entities are read-only in the UI until the status is reverted. See Data Entity Statuses → DELETED-state read-only surface for the per-affordance breakdown.

Where to next

• Catalog Overview page, Search, Directory — the three discovery entry paths that land an operator on this page.

• Entity description, Custom metadata, Per-column annotation, Manual Object Tagging, Business names, Data Entity Statuses, Data Entity Groups & Domains, Data Entity Attachments, Metadata stale — per-aspect deep dives for the panels and header affordances on this page.

• Data Lineage — the Lineage tab on every entity detail page (class-dependent visibility).

• Activity Feed — the per-entity Activity tab; the audit trail for every change applied through this surface.

• Main Concepts → Data Entity Class — the canonical class taxonomy whose enum values drive every per-class composition decision above.

• Permissions — the role-definition surface where the per-affordance permissions on this page resolve.

• Data Discovery overview — the bucket landing this page sits under.