Help us improve
Share bugs, ideas, or general feedback.
From bynder
Information architecture and Bynder asset modeling — designing metaproperty taxonomies, asset-type structures, naming conventions, and tag governance that make assets findable, governable, and integration-ready. Covers IA principles (controlled vocabularies, hierarchies, faceted navigation), modeling patterns (single-select vs. multi-select, parent/child options, asset-type scoping), and Bynder-specific mechanics (metaproperty types, filter visibility, required flags, propagation rules). Use this skill any time the user is designing, refactoring, reviewing, or migrating a metaproperty model — even when they say "set up Bynder," "design the taxonomy," "we need a new metaproperty," "this taxonomy is broken," or "should this be a tag or a metaproperty." Trigger whenever asset structure decisions are being shaped so the result holds up at scale.
npx claudepluginhub bpainter/composable-dxp-claude-marketplace --plugin bynderHow this skill is triggered — by the user, by Claude, or both
Slash command
/bynder:bynder-asset-modelThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill puts you in the role of a senior information architect fluent in Bynder as the implementation tool. Default posture: design **metaproperties as the taxonomy**, treat tags as editorial keywords only, and prefer controlled vocabularies (select / select2 with parent/child) over free-text fields.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
This skill puts you in the role of a senior information architect fluent in Bynder as the implementation tool. Default posture: design metaproperties as the taxonomy, treat tags as editorial keywords only, and prefer controlled vocabularies (select / select2 with parent/child) over free-text fields.
For Slalom Composable DXP work, the metaproperty model is where every Phase 1 Bynder decision concentrates. Get it right and the DAM compounds — assets become findable, integrations become reliable, analytics become meaningful. Get it wrong and every quarter the brand team fights the system and editors give up.
Pair with bynder-portal-architect for the multi-brand and environment shape that holds the schema, bynder-derivatives for output formats that ride on top of the model, bynder-permissions-workflow for who-can-see/edit-what, bynder-contentful-pairing for downstream CMS consumption, and bynder-migration for turning model decisions into bulk imports. If the engagement is fixing an existing implementation, route through bynder-optimization-audit first.
Channel taxonomy with values like Web > Web — Hero and Web > Web — Inline).The core distinction:
A schema that pushes everything into tags is a schema that doesn't have a taxonomy. A schema that creates a metaproperty for every editorial nuance becomes unfillable. Find the middle.
A Bynder portal is a faceted-search experience. Every metaproperty marked isFilterable: true becomes a filter. Two implications:
Channel with 7 values is a great filter. A Region with 187 values is a long scrolling list — split into parent/child or move to a different field type.For select and select2 (multi-select) metaproperties, options are first-class values:
Channel > Web > Web — Hero, Channel > Print > Print — Magazine. Bynder respects these in filtering and in the API.A metaproperty earns its place if at least two of the following are true:
If only one is true (or none), the dimension probably belongs in tags or doesn't need to exist yet.
Most engagements end up with a recognizable spine of 6–10 metaproperties:
| Metaproperty | Type | Purpose |
|---|---|---|
AssetCategory | select | Marketing / Product / Editorial / Internal — the broadest cut |
Channel | select2 | Web, Email, Social, Print, OOH, Internal — what the asset is intended for |
Brand | select | When multi-brand (otherwise inferred from sub-portal) |
BrandPillar / Theme | select2 | Strategic-narrative tagging |
Audience / Region | select2 | Persona / geographic scope |
Campaign | select (often parent/child) | Campaign + sub-campaign |
RightsStatus | select | Cleared / Restricted / Internal-only / Expired — drives permissions and filters |
UsageEnd | date | When rights expire (auto-archive trigger candidate) |
Photographer / Creator | text or reference | Credit attribution |
LegacyAssetID | text | Migration scaffold; deprecate after migration is verified |
This is a starting point, not a prescription — adapt to the client's actual asset operations.
A metaproperty for Photographer makes sense on image and video but not on document. Scope it:
metaproperty: Photographer
type: text
zip: false
isFilterable: true
zoekgebied (asset types): [image, video]
Scoping does two things: keeps the upload form clean, and keeps the filter sidebar relevant for the asset type the user is browsing.
Bias toward fewer required fields. Three classes:
Brand, RightsStatus for any commercial-use organization).isRequired. Lets editors upload work-in-progress without fighting the system.A select2 (multi-select) metaproperty is a powerful filter ("show me assets for Web and Social") but a weak governance instrument — editors will check every box. Use it when truly multi-valued (an asset can be for both Web and Social), not as a "let editors pick freely" escape hatch.
Common patterns:
Channel > {Web, Email, Social, Print, OOH} then Web > {Hero, Inline, Thumbnail}.Region > {NA, EMEA, APAC, LATAM} then EMEA > {UK, DE, FR, NL}.Campaign > {2026-Q2-Composable, 2026-Q3-Brand-Refresh} then 2026-Q2-Composable > {Hero, Email-Sequence, Social-Cut}.Three rules:
Channel > Web makes sense as a filter. Misc > Other does not.| Type | Use for |
|---|---|
text | Free-text labels (photographer name, model release ID, internal SKU). Avoid for filterable taxonomies. |
text_area | Longer free text (alt text, internal notes). |
longtext | Long-form notes. Rare. |
select | Single-value controlled vocabulary (Channel-primary, AssetCategory). |
select2 | Multi-value controlled vocabulary (Channel-allowed, Audience). |
date | Capture-date, embargo-date, rights-expiry. |
boolean | Flags (e.g., IsHero, IsApprovedForExternalUse). Use sparingly — booleans usually want to be select with two values for governance. |
| Layer | Convention | Example |
|---|---|---|
Metaproperty name (display) | Title Case, human-readable | Asset Category |
Metaproperty label (internal) | PascalCase | AssetCategory |
Option name (display) | Title Case | Out-of-home |
Option label (internal) | PascalCase | OutOfHome |
| Asset filename (uploaded) | {Brand}_{Campaign}_{Asset-Type}_{Variant}.ext, no spaces | Acme_Composable2026_Hero_Web.jpg |
| Tags | kebab-case where possible | campaign-2026-q2 |
Be consistent. Renaming after adoption is expensive.
Mark isFilterable: true only on metaproperties that earn a slot in the filter sidebar. Default rest to false. Audit quarterly and demote facets that aren't actually used (the Analytics API tells you).
Every metaproperty should have help text that answers: "When do I fill this in, and what's a good example?" Editors who upload at speed will fill in what's obvious; help text is the difference between consistent values and editorial guesswork.
1. Map asset operations end-to-end with the brand team:
what comes in, who creates it, who approves it, who consumes it,
how is it retired.
2. List the asset types in scope and the realistic asset volumes.
3. List the queries: who filters by what, in Bynder UI and in
integrations.
4. Sketch the metaproperty backbone (6–10 facets).
5. For each metaproperty: type, options, asset-type scope, required,
filterable, help text.
6. Walk an editor through uploading a representative asset; revise.
7. Walk a brand-team admin through governing an option list; revise.
8. Walk an integration developer through fetching by metaproperty;
revise.
9. Implement, with help text and validations.
10. Seed with realistic content; revise once you see the filter
sidebar populated.
Do not skip steps 6 and 7. The walkthrough catches more problems than any other step.
Metaproperty changes have downstream impact:
property_* key changes). Treat as remove-and-create with a data move.See bynder-migration for the operational pattern.
# Bynder Metaproperty Schema Proposal: [Project / Brand]
## Goals
[What the schema needs to support, tied to asset operations and integration targets.]
## Asset types in scope
[image, video, document, audio, 3D, etc.]
## Metaproperty backbone
For each:
- Display name + internal label
- Type (text / select / select2 / date / boolean / etc.)
- Asset-type scope
- Required (always / publish-time / no)
- Filterable
- Options list (with parent/child if hierarchical)
- Help text
- Downstream integrations that consume it
## Tag policy
- Allowed: [yes / no / restricted to editorial-only]
- Tag governance: [who maintains / how often pruned]
## Migration plan (if existing assets)
- Mapping from current schema/tags to target metaproperties
- Bulk-update strategy
- Editor coordination
## Brand-team walkthrough notes
- Walkthrough of governing the schema (adding a campaign option, retiring a channel value)
## Editor walkthrough notes
- Walkthrough of uploading a representative asset
## Risks and trade-offs
- Where the schema is opinionated and what flexibility was traded for what discipline
[Asset]
|- name (system)
|- type (image | video | document | audio | 3D)
|- tags (free)
|- property_AssetCategory (select) [Marketing|Product|Editorial|Internal]
|- property_Channel (select2) [Web|Email|Social|Print|OOH|Internal]
|- property_BrandPillar (select2) [Composable|Build|Insights|Practice]
|- property_Audience (select2) [B2B|B2C|Internal|Partner]
|- property_Region (select, parent/child) [NA>{US,CA}, EMEA>{UK,DE,FR,NL}, ...]
|- property_Campaign (select, parent/child)
|- property_RightsStatus (select) [Cleared|Restricted|InternalOnly|Expired]
|- property_UsageEnd (date)
|- property_Photographer (text)
|- property_LegacyAssetID (text, deprecate-after-migration)
Hero, hero, HERO, Heroes, hero-image, and is-a-hero all coexisting. Move governed dimensions to metaproperties.Photographer might be free-text (vendor names rotate); Channel should never be.IsApprovedForExternal as a boolean has no audit trail; RightsStatus as a select gives you Cleared|Restricted|... and a queryable history.Web and web and WEB as three different option UUIDs. Lock option creation to a small admin group.bynder-optimization-audit).bynder-portal-architect.bynder-derivatives.bynder-permissions-workflow.bynder-migration.bynder-contentful-pairing.bynder-compact-view.bynder-optimization-audit.../../references/bynder-foundations.md (domain + data model)../../references/api-surface.md (API decision matrix)