Consoles that show only what each engineer runs. Each engineer’s services, density and terms.
The OwnUX SDK is in development. Screens on this page are illustrative.
payments-prod · in-west-1
All services
Keyboard-first, verified
Commands that check before they act, and check again after.
Engineers act from a command bar. Each action resolves to one exact resource, is checked against your roles, confirmed where policy asks, executed through your API and read back.
- An ambiguous name asks “which one?” before anything changes.
- Your roles decide. OwnUX holds no permissions of its own.
- Actions you leave out of the manifest are never offered.
- resolvebilling-api → svc_8f2 in payments-prod
- checkdeploy permission: granted by your roles
- confirmRoll back 3 instances to revision 41? Confirmed
- executerollback requested · key 7c1e
- verifyread back: revision 41 · 3/3 healthy
- done✓ verified in the console
If OwnUX can’t do it, it says so, changes nothing and links to your standard console.
Set once by each engineer. The console follows each engineer’s Interface DNA. Access and data stay where they are.
Only my services. Hide every service you don’t run. The whole catalogue is one click away.
Density. Comfortable while you learn the console, compact when you’re scanning alerts at 3 a.m.
Terminology. Plain names for new joiners, resource IDs and region codes for experts. Meaning is always kept.
Shortcut scheme. Keyboard-first or pointer-first, with the shortcuts each engineer already knows.
Contrast and motion. Dark or high-contrast themes, larger text and reduced motion when they ask for them.
Recent-first navigation. Start from what you touched last, or from the project, whichever you prefer.
For your platform team
Your console, your components, your rules. OwnUX renders with your design system and steps aside the moment anything is wrong.
Declare what OwnUX may offer and which screens it must never touch. It uses your components and roles, and falls back to your standard console if the manifest is invalid.
- Map OwnUX’s 17 building blocks to your own components.
- Locked screens, rollout, holdout, kill switch: all in your code.
- ownux test checks L1 Declared and L2 Verified today.
import { defineManifest, OwnUXProvider } from "@satin/ownux"; export const manifest = defineManifest({ app: { id: "acme-console", version: "3.2.0" }, actions: { /* the actions you choose to offer */ }, // Screens OwnUX never renders, whatever a person asks for. locked: ["billing", "security", "consent"],}); <OwnUXProvider manifest={manifest} binding={binding} components={consoleComponents} user={{ id: engineer.id }} rollout={{ percentage: 25, holdout: 0.1, salt: "console-1" }} onNativeView={() => showClassicConsole()}/>Where the SDK is today. Numbers that are true now, and the one that is a target.
- building blocks you map to your own components
- 17building blocks you map to your own componentsIn today’s SDK alpha
- conformance levels checked by ownux test v0
- L1 · L2conformance levels checked by ownux test v0L3 Adaptive is planned
- the first supported frontend
- React 19the first supported frontendOther frameworks later
- size budget for the SDK
- 60 KBsize budget for the SDKA design target. The alpha measures 52.8 KB
In developmentThe OwnUX SDK and Reference App exist in development, and the alpha covers tasks. Console screens like the ones on this page need capabilities beyond the alpha. A developer portal is planned.
Questions, answered.
No. Filters, density and terms change what a person sees, not what they’re allowed to do. Your roles and policies stay in charge, and the full catalogue is one click away.