​

Proposing new certifications and traits

Listings use controlled pick-lists for health certifications/tests and traits. If you don’t see the option you need, you can propose a new one from the listing flow. This proposal flow exists to keep the marketplace consistent (so buyers can filter and compare listings) while still letting the taxonomy grow safely over time.

​

When to propose a new certification

Use Propose a new certification when the animal has a real, relevant health certification or test result that isn’t available in the list for the selected category/species. Examples:

• “TB Tested Negative”
• “Brucellosis Tested Negative”
• “Coggins Test” (equine)

​

When to propose a new trait

Use Propose a new trait when you want to describe a recognized, non-medical trait that isn’t available in the traits list. Examples:

• “Docile Temperament”
• “Good Layer”
• “Dual Purpose”

​

What happens after you submit

Both “propose certification” and “propose trait” use the same backend workflow.

​

1) Basic validation and access checks

• You must be signed in.
• The suggestion name is required and must be (\le 100) characters.
• A listing category must be selected (this is what scopes the suggestion to the right schema).
• Requests are rate-limited (per user).

​

2) The system loads the current “official” options

For the selected category (and species, if available), the backend loads the current pick-list options from detail_schemas.schema_json (the health section field options arrays):

• Certifications: the health_certifications field options
• Traits: the traits field options

​

3) The system checks pending proposals too

Before considering anything “new”, the backend also loads any pending proposals from proposed_benefits for the same category/species scope. This prevents duplicates when someone else already suggested the same thing and it’s waiting for review.

​

4) Deduplication and normalization run before anything is stored

The backend normalizes labels (case/punctuation differences) and rejects anything that’s already covered by:

• An existing official option, or
• A pending proposal

For certifications/tests, the backend also deduplicates at the disease level (so “Brucellosis Vaccination …” won’t be treated as “new” if brucellosis is already covered by an existing test/cert option). For traits, the backend checks exact matches and near-duplicates/synonyms (for example: “Calm Temperament” vs “Docile Temperament”).

​

5) AI moderation decides whether it belongs in the taxonomy

If it isn’t a duplicate, the backend uses an AI moderation prompt to decide whether the suggestion fits one of the allowed categories:

• Official certification/test
• Care practice
• Recognized trait (seller-declared, non-medical)

It will reject suggestions that are:

• Species-inappropriate (for example: poultry-only programs on non-poultry species)
• Unverifiable guarantees (for example: “disease free”)
• Marketing fluff or subjective hype
• Unsafe/illegal/harmful content

​

6) If approved and truly unique, it’s saved for admin review

Only suggestions that are both:

• Approved, and
• Unique (not duplicate / not too similar)

…are inserted into proposed_benefits with status pending.

​

7) Admins approve or reject

Admins can:

• Approve: the label is appended into the correct schema options array (certifications → health_certifications, traits → traits) so it starts appearing in the listing UI.
• Reject: the proposal is marked rejected and does not become selectable.

​

Why the “explanation” matters (and why we ask for it)

The proposal name alone is often ambiguous. The explanation is what lets the system and admins evaluate it quickly and safely. Including context helps:

• Prevent misleading claims: buyers rely on these fields when evaluating health and suitability.
• Keep filters/search useful: a consistent label taxonomy is what makes filtering comparable across listings.
• Reduce duplicates: many items are the same thing phrased differently; context helps pick the right standardized label.
• Avoid species mistakes: some certifications/tests only apply to specific species.
• Speed up review: clear context reduces back-and-forth and speeds approvals.

​

What to include in your explanation

​

For certifications/tests

• The issuing program/authority (if you know it)
• What the test/cert covers (and what it does not cover)
• When it was issued/performed (approximate is fine)
• Whether you can provide documentation (see /help/listing-documents)

​

For traits

• What you mean in observable terms (how someone would verify it)
• Whether it applies broadly (not a one-off marketing phrase)
• Avoid medical claims (keep it non-medical)

​

Common rejection reasons

• It’s already covered by an existing option (or already pending)
• It’s too similar to an existing trait
• It’s not applicable to the selected species
• It’s not a standardized label that belongs in a controlled list

If you’re unsure, choose the closest existing option and add detail in the listing description and/or documents. You can also review the platform’s standards in /help/moderation and /help/trust.