Listing Platform Product Review Sandbox

Atlas HydrationUnited States

Deep implementationADM-005

Active policies

3

Artifact classes governed

18

Required client review

1 policy

Overrides this quarter

3

Creative + claims controlled approval

Used when creative contains measurable performance, testing, ingredient, or compliance-sensitive statements.

Reviewer sequenceClient review

Decision SLA8 hours

Publishing gateRequired

Reviewer sequence and authority

1

Compliance ReviewerRequired decision

Required

2

Brand DirectorRequired decision

Required

2

Client ReviewerAdvisory / optional

Optional

3

Listing DirectorRequired decision

Required

Policy triggers

Artifact typeGraphic Strategy, Core Images, A+ Content, Sponsored Brands

Claim sensitivityMeasured or regulated claims

Scope expansionNew marketplace requires new approval

Version changesAny successor invalidates prior approval target

Override and audit rules

Overrides require administrator authority and a recorded business reason.
Overrides expire and cannot silently become the new policy default.
Every approval, waiver, delegation, and override is written to the immutable audit log.
Required compliance review cannot be overridden for prohibited or unsupported claims.

What this page is supposed to answer

Who can do what?
Which definitions, policies, and integrations power the operating system?
What changed, who changed it, and what downstream behavior did it affect?
What should a Platform Admin, Listing Director decide or understand here?

Why it exists

Administration governs the registries, policies, integrations, permissions, taxonomies, and audit history that keep the platform coherent as it grows. This specific page exists to configure required approvers, sequence, quorum, section/field/artifact granularity, client review, and downstream gates.

How to use it

Start with the page header to confirm the screen, scope, and review status.
Read the primary cards or table as the operating surface for the current decision.
Use the element info buttons to inspect why a region, component, action, or state exists.
If the page feels wrong, add a Review Mode call-out and then save an explanation update describing what changed and why.

Important nuance

Execution definitions should be governed data, not scattered hard-coded workflows.
Policy changes affect downstream approval, publishing, automation, and permission behavior.
Administrative edits should leave an audit trail because they change how the platform reasons.
Used when configuration changes may affect permissions, workflows, registries, or future behavior.
Old and new explanations should both remain available because product decisions are part of the system history.

Current explanation version

Architecture baseline2026-07-16 / Architecture conversation

What: Initial product guidance for Approval Policies.

Why: Generated from the Listing Division architecture, screen map, navigation spec, execution ontology, component system, and sandbox implementation.

Guidance: Approval Policies should configure required approvers, sequence, quorum, section/field/artifact granularity, client review, and downstream gates.

policy listapproval graphconditionsapprover rolesSLAescalation

Architecture signals

Screen map: ADM-005Surface: AdministrationTemplate: SettingsPageTemplateEntities: artifact, review_request, approval_requestStates: Draft, Active, Deprecated, Conflict