Skip to content

Property Intents

Purpose

This document defines intent for product-domain properties managed through the marketing BFF.

Properties are reusable vocabulary objects. They should be treated as first-class product-domain assets rather than as incidental fields embedded ad hoc into products.

Typical examples include mechanical, electrical, dimensional, and packaging attributes used in:

  • BoP
  • BoM
  • product display
  • structured filtering
  • configuration guidance

Role of Properties

Properties exist to make product structure explicit and reusable.

They support questions such as:

  • which properties are related to solar racking mechanical systems?
  • what properties are already defined for battery packaging?
  • does a pillar-type property already exist?

They also support mutation requests such as:

  • add a property definition Rack Pillar Type A
  • update property Rack Pillar Type A

Retrieval Intent

The current BFF retrieval endpoints for properties are:

  • getProperty(propertyKey)
  • getPropertiesByKeys(propertyKeys)
  • getPropertyHeaders(filters)

Recommended retrieval pattern:

  1. use getPropertyHeaders for discovery and candidate narrowing
  2. use getProperty for exact inspection
  3. use getPropertiesByKeys for batch hydration after discovery

Mutation Intent

The current deployed product-bff does not expose verified live property-definition mutations.

Operational rule:

  • do not assume createProperty(input), updateProperty(propertyKey, input), or deleteProperty(propertyKey) are currently available live
  • use property retrieval for discovery and alignment work
  • treat property-definition writes as blocked until re-verified against the deployed schema

Current Property Shape

The live property model currently uses:

  • propertyKey
  • name
  • propertyBase
  • unitHint
  • sequence
  • description

It does not use:

  • type
  • unit

Human Input Pattern

Property intent should support human requests like:

  • add a property definition Rack Pillar Type A
  • rename property Old Rail Type to Solar Rail Type
  • show me all racking-related properties

The assistant should:

  1. search for near matches first
  2. avoid duplicate property creation
  3. use the canonical BFF property fields for retrieval and alignment
  4. stop short of claiming a live property-definition write path until it is re-verified

Discovery Direction

Property retrieval will benefit from a discovery layer that can map domain phrases such as:

  • solar racking mechanical systems
  • pillar type
  • mounting hardware

to candidate properties before exact BFF retrieval.

That layer should help resolve intent. It should not replace the BFF as the system of record.