The JSON editor was technically usable. Nobody could actually use it.
Customers routinely extend Ataccama ONE’s metadata model with custom properties, Region, Data Owner, Classification. The historical way to surface them on entity detail pages was a Monaco-based JSON editor hidden behind a feature flag, unusable by anyone who didn’t write code.
Customer-facing teams complained when the flag came off. The brief: remove the JSON editor entirely and replace it with something an admin or a consultant could actually use.
Real demand, no real solution.
The product inbox held the evidence, concentrated demand across DG, DQ, ONE Platform, and Agentic, going unaddressed because the existing solution was developer-only.
The audience was specific: tenant admins and consultants, people who understand the metadata model conceptually but don’t write code. Explicitly not for end users or developers.
One escape hatch. Everything else locked.
A model with a single customizable surface. Admins pick which properties matter most, and those properties surface at the top of every entity page of that type, pinned into the Summary. Everything else stays on a default layout that Ataccama curates and locks.
The pattern is "shell-plus-accent", universal across every competitor I studied (Jira, Collibra, Salesforce, Atlan, Harness, ServiceNow). A dominant, system-controlled layout with one explicit surface for promoting individually-important content.
The whole thing is configured in one place: Settings, Metadata Model, the entity type’s Pinned properties tab. The admin picks individual properties from a searchable list, scoped to the tenant, and every instance of that entity type inherits them. No JSON, no code.
Config: the admin picks properties to pin to the Summary, per entity type, in Settings.
Result: the pinned properties surface at the top of every entity page of that type.
Each one came from a finding in the research.
V5 wasn’t my first idea, it was synthesis. Without V1–V4 showing what didn’t work, V5 would have looked like V1.