Admin Tools and Preferences Audit Update

Another important layer of Apex Infinity became real this week: the platform now has an internal admin support surface instead of relying on ad hoc lookups and external payment-console access for routine questions.

At the same time, we also stepped back and audited how preferences are supposed to move between Companion, Core, and the Wrist, because that part of the product is starting to matter more as the device behavior gets richer.

These are not flashy features in the same way Face Studio, checkout, or synced UX ownership are. But they are the kind of work that makes the platform much easier to support, reason about, and keep coherent as it grows.

The admin side got much more usable

The website now has a restricted admin area that only appears for signed-in accounts that belong to the admin group.

That matters because support tooling should not require full infrastructure access, and it should not depend on signing into payment systems directly just to understand what happened to a user account.

The new admin flow can now do several things that previously required piecing together information from multiple places:

• look up an Apex account by email
• inspect paid entitlements and library membership together
• show whether a paid UX item is fully fulfilled or missing a library row
• show purchase and fulfillment diagnostics in a more support-oriented way
• display payment-related detail inside the admin interface instead of kicking the operator out into a separate operations console

That is a meaningful quality change for the platform. It makes support and operations less brittle, and it creates a cleaner boundary between “product admin work” and “payment account ownership.”

The account story got stronger too

This work also helped round out the account side of the website.

The platform now has a clearer place for users to see what they own, what they purchased, and how that ownership is represented across the website and Companion. That was already becoming more important once paid creator UX moved into real test-mode checkout, but it becomes even more important once support and admin tooling start relying on the same account model.

In other words, this is not just about adding internal tools. It is about making the ownership system easier to inspect from both sides:

• the user side
• and the support side

That is part of what turns commerce and library restore behavior into a trustworthy platform feature instead of a black box.

We also audited how preferences are really flowing

The other major thread this week was a full audit of the Companion preferences model against actual Core and Wrist behavior.

That turned out to be useful because the system is not as simple as “everything in Preferences goes everywhere.”

What we found is closer to this:

• some preferences are genuinely shared between surfaces
• some belong to device behavior
• some belong to display behavior
• and some legacy fields are not doing anything meaningful at all

That is exactly the kind of mismatch that is easy to live with in an early prototype and much harder to live with in a product.

The audit is now giving us a clearer way to sort the next round of work:

• turn already-exposed preferences into real runtime behavior where they are still only being parsed
• separate shared settings from device-only and display-only settings more intentionally
• replace temporary derived preference behavior with more explicit user-controlled behavior
• make a few long-standing stored preferences actually drive the parts of the product they were meant to affect
• and clean up legacy preference state that no longer reflects the current product direction

This is not just cleanup for its own sake. It is how the device behavior starts matching the product language in the Companion app.

Why this phase matters

The more connected Apex Infinity becomes, the more important these “middle layer” systems become.

It is no longer enough for each surface to work in isolation. The website, Companion, Core, Wrist, and the account/ownership model all need to describe the same reality:

• what a setting means
• where it is supposed to take effect
• who owns a purchase
• whether fulfillment actually completed
• and how support can verify that without guesswork

That is the less glamorous side of product maturity, but it is real maturity.

What is next

The immediate follow-on work from here is fairly clear:

• implement the preference behaviors that are already exposed in Companion but still not active in Core or Wrist
• improve the Wrist-side visual handling for those alert preferences
• keep extending admin/support tooling in safe, support-oriented ways
• and continue refining the purchase and ownership system before the creator payout layer is introduced

So while this update is less about a single headline feature, it is still an important step.

Apex Infinity is getting better not only at delivering features, but also at explaining itself, supporting itself, and behaving more consistently across all of its surfaces.