OwnUX

Abstract

Software is designed once and used by everyone. People adapt to it: they relearn layouts, labels and journeys in every product, and the people with access needs, little time or an unfamiliar language pay the highest price. OwnUX reverses that relationship.

A person defines their user experience once, as a portable profile they own called Interface DNA. An application declares what it can do as a set of typed capabilities. A deterministic Experience Translation Engine composes an interface from the application’s own approved components to fit that person, and a runtime verifies every action against the application before reporting it done. This document defines the OwnUX model, its five components, its data and security model, and three levels of conformance that let products declare and prove support.

1. Introduction

Every product team designs for an imagined average user and for the administrator who configures the workspace. Beginners and experts share one crowded default. Someone who works across four tools learns four ways to do the same few things: find my work, change its status, set a date, see what is blocked. Organisations pay for this in onboarding, errors and support. People with access needs pay for it in exclusion.

There is already proof that a better model works. Operating systems let a person choose Dark Mode, larger text or reduced motion once, and the web exposes those choices to every site through user-preference media features such as prefers-color-scheme, prefers-reduced-motion and prefers-contrast. Millions of products now honour them. But those preferences stop at colour, contrast and motion. Layout, density, navigation, wording, guidance and language remain fixed by each vendor.

OwnUX is not a theme engine, an autonomous agent, a generator of free-form interfaces, or an accessibility certification. It is a contract between three parties: the person, who owns their preferences; the application, which owns its capabilities and data; and a runtime that translates between them and verifies everything it does.

2. Definition and terms

OwnUX is a human–computer interaction technology, open specification and design discipline through which a person defines their own user experience once, and software renders itself to fit it.

Applications declare their entities, capabilities, permissions and constraints. An OwnUX runtime translates them into interfaces shaped by the person’s preferences, current intent and context. The application keeps authority over data and permissions, and the original interface stays one action away.

3. Design principles

Every part of the specification follows from eight principles. Where a design choice conflicts with one of them, the principle wins.

4. Architecture

OwnUX has five components: the capability model, Interface DNA, the Experience Translation Engine, the OwnUX Runtime and the conformance suite. The runtime is one codebase with two hosts. In the Satin extension, adapters bind existing third-party applications to the capability model through their official APIs. In the OwnUX SDK, a product binds its own API handlers and renders surfaces with its own design system.

The person

Sets preferences once

Interface DNA

• Layout and density
• Words and reading level
• Interaction and shortcuts
• Contrast, text size, motion
• Language and locale

preferences in, surfaces out

OwnUX Runtime

Runs in the Satin extension or inside a product through the OwnUX SDK

Experience Translation Engine

Composes the interface

Action Broker

Executes and verifies

Policy

Risk, consent, locked surfaces

capabilities, actions and read-back

The application

Stays in charge

Capability manifest

Official API

Design system

Data and permissions

Conformance suite · ownux test checks the manifest, every action and the rendered surfaces

5. The capability model

A capability is the unit of meaning in OwnUX. It names an entity and a permitted action, such as task.set_due_date, and carries everything the runtime needs to perform it safely: the input schema, a risk level, preconditions, how to execute, how to verify and what to do if it cannot. Canonical names let one interface pattern work across every product that binds to them.

import { defineManifest } from "@satin/ownux";
import { api } from "./api";
 
export default defineManifest({
  app: "acme-projects",
  version: "1.4.0",
  entities: {
    task: { id: "string", title: "string", status: "enum", due: "date" },
  },
  actions: {
    "task.set_due_date": {
      input: { task: "task.id", due: "date" },
      risk: "reversible_write",
      preconditions: ["authorised", "unambiguous", "field_editable"],
      execute: api.tasks.update,
      verify: api.tasks.get,
      fallback: "deep_link",
    },
  },
  locked: ["billing", "security", "consent"],
});

Risk levels

For existing products, an adapter maps canonical capabilities onto the product’s official API. Adapters are declarative data, run by a generic interpreter, so they can be reviewed and tested like any other contract. They never use undocumented endpoints or read session tokens from a page.

6. Interface DNA

Interface DNA is the person’s side of the contract: a small, versioned, human-readable profile. It is explicit first. A person sets it in a two-minute setup or skips it, and can change any axis at any time. Products read only the axes they understand, and only the axes they have been granted.

{
  "format": "ownux-dna/1",
  "updated_at": "2026-10-23T10:00:00Z",
  "explicit": {
    "density": "compact",
    "navigation": "task-first",
    "layout": "list",
    "words": "plain",
    "interaction": { "mode": "keyboard-first", "shortcuts": "default" },
    "guidance": "minimal",
    "visual": { "contrast": "standard", "text_scale": 1.0, "reduced_motion": false },
    "locale": { "language": "hi-IN", "time_zone": "Asia/Kolkata", "week_start": "monday" },
    "change_policy": "preview-first"
  },
  "learned_suggestions": [],
  "sharing": { "sync": false, "grants": [] }
}

Learned preferences are optional and arrive only as suggestions. The person can open “Why was this suggested?”, then accept, edit or decline. The format is versioned (ownux-dna/1) with defined migrations, so a profile outlives any one product.

7. The Experience Translation Engine

The engine turns capabilities and preferences into a surface. It is deterministic: the same inputs always produce the same interface, which makes surfaces testable, reviewable and predictable for the person using them. It composes only from components the product has registered, so an adapted interface still looks and behaves like the product, not like Satin.

Machine learning may propose layouts or explain changes, but it never authorises an action, chooses an endpoint or writes code into a page. Every proposal passes the same schema and policy validation as a hand-written template, and the engine must work fully without it.

8. The runtime and verified actions

Changing how software looks is easy. Changing what it does, safely, is the hard part. The Action Broker treats every write as a transaction with six steps, and a person is only told “done” after the result has been read back from the application.

Correctness rules

• Identifiers are never invented. Ambiguous matches are resolved by asking the person.
• The source’s last-updated value is captured before a write. If it changed, the conflict is shown rather than overwritten.
• Date-only fields receive date-only values, resolved in the person’s own time zone.
• Retries are idempotent. A rate-limited or unavailable source produces a safe failure, never a false success.
• Interface undo (a layout change) is kept separate from source undo (a data change).

Design targets for the runtime: a surface renders in under 300 ms from cached data and a verified action completes in under two seconds at the 75th percentile, with no measurable input latency added to the original page.

9. DNA Share

DNA Share connects a person’s profile to products that build OwnUX in natively, so a new product can feel familiar from the first minute. It uses OAuth 2.0 authorisation code with PKCE. The person sees every requested scope and can untick any of them. The product receives only the granted values, never usage history, other apps or work content.

{ "layout": "list",
  "density": 0.22,
  "words": "plain" }

Scopes map one-to-one to Interface DNA axes: dna:layout, dna:density, dna:words, dna:interaction, dna:accessibility and dna:locale. When the Satin extension detects a product with OwnUX built in, it stands aside so that a page is never adapted twice.

10. Infrastructure and data residency

OwnUX is local-first. For people using existing applications, the runtime calls those applications’ APIs directly from the person’s browser, so task titles, descriptions and comments never pass through Satin. For products with the SDK, the runtime runs in the product’s own frontend and data flows from the product’s backend as it always has.

Token custody and configuration

Where a provider supports public clients with PKCE, the extension completes sign-in itself and no Satin server sees a token. Where a provider requires a client secret, a stateless relay adds it and returns tokens straight to the extension without storing or logging them. Remote configuration carries flags only (a kill switch, adapter enablement and feature flags), is signed, and never adds new behaviour. Every change in behaviour ships as reviewed code.

11. Security model

OwnUX sits between a person and software they rely on, so its threat model is part of the specification, not an afterthought.

12. Conformance

Support for OwnUX is something a product proves, not something it claims. Three levels build on each other, and each is checked by the same open test suite.

$ npx ownux test
 
  ✓ Manifest valid                              L1 Declared
  ✓ 12 actions execute, verify and fall back
  ✓ Permission-denied paths are safe            L2 Verified
  ✓ Accessibility checks passed on 9 surfaces
  ✓ Locked surfaces untouched                   L3 Adaptive
 
  Eligible for the OwnUX Ready badge (L3).

13. Paths to adoption

OwnUX is designed to reach people through three paths, each useful on its own.

The third path is a long-term proposal, not a dependency. Features such as a density or reading-level preference would let any website honour part of a person’s Interface DNA without an SDK, in the same way prefers-color-scheme made Dark Mode universal.

14. Prior work

OwnUX stands on a long line of research and practice. Its contribution is the combination: a capability-translation layer between existing applications and the person, with portable, user-owned preferences, verified actions, a native fallback, and an open specification that vendors adopt and certify against.

15. Open questions

This is a working draft. These questions are open for comment before version 1.0.

• How should plain-language and reading-level transformations be measured and certified?
• When organisational policy and personal preference conflict, which axes may each override?
• How should shared devices and multiple profiles per person work?
• Which standards body is the right long-term home for the specification and the preference features?
• How should OwnUX interoperate with agent-to-UI protocols without giving up verification?
• What is the right licence for the specification text and the reference schemas?

16. Attribution and citation

The specification is intended to be open so that anyone can implement it. Satin is its first implementation. When referring to OwnUX, please use the attribution above and cite this document.

Cite as: Goswami, P. (2026). OwnUX: An Open Specification for Software That Fits the Person Using It (Version 0.1, working draft). Satin.

@misc{goswami2026ownux,
  author = {Goswami, Pranav},
  title  = {OwnUX: An Open Specification for Software
            That Fits the Person Using It},
  year   = {2026},
  month  = {October},
  note   = {Version 0.1, working draft},
  publisher = {Satin}
}