Skip to content
Arc XP

Compass Admin UI: Editorial Controls

The Compass Admin UI is where your newsroom watches how personalized recommendations are performing and takes the one editorial action that is available without writing code: pinning a story to the top of the recommendation list.

This page covers the editorial controls. For how to read the numbers the same app shows you, see Compass Admin UI: Reading Your Analytics.

Getting oriented

Compass lives at /compass in your Arc XP environment. Opening it takes you straight to the Overview, the analytics dashboard for the first of your websites.

The left column has two things in it:

  • A website selector. Every editorial control and every metric in Compass is scoped to one website. A website is always selected — if you manage several, check the selector before you read a number or pin a story.
  • Section links. Overview is the analytics dashboard. Editorial controls is the subject of this page.

Pin a story

Editorial controls hosts a single panel, Pinned Story. Pinning places one story at the top of the personalized recommendation list for every reader on the selected website, and leaves the rest of the list personalized as usual.

Two constraints to know before you use it:

  • The position is always 1. The Admin UI pins to the top slot. It does not offer a choice of position.
  • The pin takes effect immediately. There is no start time or schedule field — a pin you save is live on the next recommendation request. If you need a pin that starts later, use the Editorial Signals API.

Create a pin

  1. Select the website in the left column.
  2. Go to Editorial controls. With nothing pinned you’ll see No story pinned and a Pin Story button.
  3. Search for the story by headline. The search runs against your organization’s content catalog.
  4. Choose the story, then set an expiration (below).
  5. Save. The pin is live immediately.

Set an expiration

Expiration is optional. You can:

  • Use a quick preset — +8h, +12h, or +24h. Presets resolve to “now plus N hours” at the moment you click them, not at the moment you save.
  • Use Custom to pick an exact date and time. A time in the past is rejected.
  • Set nothing at all, which reads as No expiration — the pin stays up until someone removes or replaces it.

Clicking a preset that is already active clears the expiration again.

Replace or remove a pin

With a story pinned, the card offers two actions:

  • Replace reopens the same form, pre-filled. Saving swaps the pinned story in a single atomic update — there is no window where the website has no pin.
  • Unpin removes the pin after a confirmation prompt. Unpinning affects only the selected website; you can pin a different story straight afterward.

The pinned card also shows the story’s byline and publish time alongside its own Impressions, Clicks, and CTR for the last 24 hours. If the story was pinned recently you may see No analytics for this story yet — analytics is minute-grain and needs traffic before it reports. Analytics unavailable means the metrics request itself failed, not that the story earned nothing.

The one-pin-per-website limit is in the UI, not the API

The Pinned Story panel offers a single pin slot, and its subtitle states the convention: one pin per website with duration. That limit belongs to the Admin UI. The Editorial Signals API does not impose it — so don’t build on “there can only be one pin” as a platform guarantee.

What each layer does:

  • The Admin UI shows one pin per website. It looks for pins whose start/end window contains the current moment and displays the most recently created one.
  • The Editorial Signals API accepts several. Pin uniqueness is per item — one pin per organization + website + item + signal type — so multiple pins can be active on one website as long as they name different stories. Re-pinning a story that is already pinned on that website returns 409.
  • Recommendation serving applies all of them, in ascending position order.

Why isn’t my pin showing?

A pin reorders a story that recommendations were already able to serve; it does not inject one that the model didn’t surface. When the reranker applies pins, it skips any pin whose story isn’t in the candidate set the recommender produced for that request. The recommender pulls more candidates than it returns, which leaves some headroom — but that headroom is finite.

In practice this means a pinned story can be missing for a specific reader while appearing normally for others, because candidates are personalized per reader. Before assuming something is broken, check:

  • The website. Pins are per website, and the Admin UI scopes to the one selected in the left column.
  • The expiration. An expired pin stops being applied silently.
  • Whether the story is a plausible recommendation at all. A story that is not in the recommender’s catalog, or that the model never surfaces for the reader you’re testing with, will not be pinned into view. Very old stories and stories published moments ago are the usual suspects.
  • Whether you’re comparing like with like. Pinning affects personalized recommendation lists. It does not reorder popular or trending responses.

Boost, bury, and exclude are configured through the API

Compass exposes pin only. The recommender supports four editorial signal types — boost, bury, pin, and exclude — and honors all four at serving time, but the other three have no control in Compass. You configure them through the Editorial Signals API (/signals/v1), either from an automated rule in your content ingestion pipeline or from a curation tool you build.

For what each signal type does, how weights and scheduling work, and the request shapes, see Editorial Signals in the Content Recommendations API.

That API is also where you go for the things the pin form doesn’t cover: pinning to a position other than 1, scheduling a pin to start in the future, or running more than one pin on a website at once.