# Applications

One supports two honest application models. A contract-driven web application
can use the first-party [One Web framework](/one/guides/one-web). An application
can also use an ordinary web, mobile, desktop, terminal, or device framework
without turning that framework into a One renderer.

## Let a framework-native application own its interface

Routes, screens, components, loaders, actions, navigation, local state,
styling, accessibility, interaction, and framework upgrades belong to the
application. Use React, Next.js, SwiftUI, Compose, Flutter, Tauri, native
terminal libraries, or another selected framework directly.

These applications do not acquire One Web places, presentation state, or
realization claims merely because they use generated clients. If an external
application needs to claim an exact Experience realization, it submits the
admitted mapping and conformance evidence explicitly; One never infers that
claim from routes, component names, rendered HTML, or package presence.

The application consumes narrow One contracts where they provide value:

- nominal values, schemas, validation, and codecs;
- operation clients and server bindings;
- authentication and scoped capabilities;
- typed state and streaming interfaces;
- Build artifacts, deployment bindings, and runtime configuration;
- observations, causal references, and inspection envelopes.

## Give each application its own root

A browser, API, worker, migration, and operator interface should normally be
separate roots. The browser closure includes public schemas and client
credentials, not database drivers or server secrets. The operator closure can
request inspection and bounded control capabilities without entering the
customer application.

Shared UI or domain packages create explicit contract edges. Workspace
membership does not merge roots.

## Generate only mechanical bindings

Client generation projects owned contracts into the target language: nominal
types, validators, codecs, operation calls, faults, and selected protocol
bindings. A projection receipt records the contract revision, profile,
toolchain, output, and loss.

Generated application shells, authentication flows, framework state, and
product behavior are avoided because their value is not mechanical projection.
Those remain ordinary maintained application code.

## Keep live development honest

The development session may compose framework servers, typed API children,
watchers, local providers, and source maps for one exact root. Its state is
disposable and its authority is explicitly local.

Development readiness, simulation, and fixture data do not become Build,
release, hosted, or production evidence. Production follows the same contracts
through exact planning, Build, apply, and inspection.

## Render product truth, not platform internals

End-user screens describe the user's work, choices, progress, and actionable
outcomes. Internal stage names, provider wiring, raw faults, proof counters, and
architecture evidence stay out of ordinary product chrome.

Deliberate configuration, troubleshooting, and evidence views may expose the
smallest relevant technical state translated into user-actionable language.
Glass-box inspectability remains available without turning every screen into a
debugger.

## Example

Illustrative TypeScript uses a generated client while the framework keeps its
own route and component model:

```typescript
const result = await orders.get({ customerId, orderId });
if (result.kind === "success") return <Order order={result.value} />;
if (result.kind === "domain_fault") return <NotFound />;
return <Unavailable state={result} />;
```

Follow [Use One from a framework-native application](/one/examples/framework-application).
Mobile, desktop, terminal, and device variants are covered in
[Build other application targets](/one/examples/application-targets).

See also [roots and composition](/one/model/composition) and
[languages and SDKs](/one/platform/languages).