One is a System-IDL-first platform for declaring, implementing, testing, building, shipping, governing, and operating complete software systems. You describe stable meaning once. One carries that meaning through every physical choice and retains the evidence needed to explain the result years later.
This site defines the finished product: the experience and guarantees of One as a mature platform. Availability depends on the installed release and exact selected profiles; an end-product description alone does not establish support. Executable examples identify their owning implementation evidence, and other examples are illustrative.
One connected lifetime
Software outlives frameworks, clouds, teams, credentials, protocols, and deployment tools. One gives the parts that must survive those changes stable owners and exact identities.
| Your system needs | One retains |
|---|---|
| Meaning | domains, schemas, operations, faults, effects, and compatibility |
| Behavior | implementation claims, source closure, language analysis, and conformance |
| Composition | independent root closures and a proof for every inclusion |
| Physical realization | providers, topology, conversions, resources, and cost |
| Authority | requirements, policy, grants, tokens, enforcement, and approvals |
| Supply chain | actions, artifacts, SBOMs, provenance, signatures, and attestations |
| Change | semantic impact, migration, rollout, coexistence, and removal conditions |
| Operation | observations, causal facts, reconciliation, recovery, and erasure |
The ordinary path stays compact. The underlying records stay separate so convenience cannot hide consequence.
Declare meaning, not today's infrastructure
System IDL describes product meaning: nominal data, operations, services, state, workflows, effects, authority requirements, roots, and composition. It does not choose a database, cloud, queue, runtime, serializer, or UI framework.
Implementation bodies can live beside semantic declarations in .one source,
but remain isolated artifacts interpreted by their exact language profiles.
An implementation claim is not trusted because it parses, selected because it
exists, built because it was selected, or authorized because it was built.
Compose the smallest fitting system
One can realize an edge as a static call, task, Wasm component, supervised process, remote service, durable workflow, managed capability, or a deliberate combination. It prefers the narrowest boundary that satisfies the root.
Crossing a boundary adds the real costs and failure modes: identity, codecs, transport, deadlines, cancellation, retries, partial outcomes, state movement, observation, and money. Staying local keeps them out.
Make every root an independent product
A browser, API, worker, migration, operator, device, and provider can share a workspace without sharing closure. Each root receives only its reachable code, schemas, providers, artifacts, resources, secrets, and grants.
This is how One makes least authority, small artifacts, bounded blast radius, and replaceable infrastructure consequences of composition rather than cleanup projects.
Use established systems without surrendering ownership
Providers realize owned contracts through native implementations or adapters to databases, clouds, queues, identity systems, build tools, orchestrators, model providers, and observability backends. The application continues to depend on the smallest public contract.
Planning selects exact provider profiles eligible under the root's assurance policy, explains rejected alternatives, and commits topology, cost, evidence requirements, and the maximum authority envelope. Build retains the separate realization evidence; grants and runtime activation follow at their owning stages. Installing a provider does nothing by itself. Switching outside a released envelope requires a new plan.
Treat production as evidence, not a different universe
Local development and production use the same semantic model. Assurance grows with consequence: production can require stronger isolation, signing, admission, approval, rollout, independent observation, retention, and recovery.
Unavailable behavior returns Unsupported, Unsatisfied, or missing evidence.
A timeout after dispatch returns outcome unknown. One never invents success,
silently removes a requirement, or treats a plan as permission to mutate.
Operate the system you actually released
Inspection resolves exact owner records and answers why a dependency exists, which provider and artifact are active, what authority was granted, which actions occurred, how fresh the observations are, and what would change the result.
Rollback, failover, restore, migration, rotation, and compensation are new forward operations. External history is not rewritten. Humans, automation, and AI agents use the same typed operations, approvals, and evidence.
Choose your path
- New to One: install One, build your first system, then learn the mental model behind what you just ran.
- Ready to author: learn the
.onesource language, domains and traits, and product declarations. - Building an application: use One Web for a contract-driven web root or keep an ordinary application framework behind explicit One contracts.
- Working interactively: use One Shell for host tools and typed lifecycle operations, with the local daemon as an optional accelerator.
- Working across teams and providers: use the optional One Cloud console over the same public owner operations and evidence.
- Learning by example: choose a task from examples and recipes, then follow it from declaration to evidence.
- Designing a system: start with source and meaning, data and state, and roots and composition.
- Shipping production: follow plan, build, and apply, deployment, and recovery.
- Building a platform: read providers and adapters, semantic domains, and multi-tenant platforms.
- Building around state: start with One Database and dependencies and toolchains.
- Evaluating the contract: use product guarantees, the failure model, and the architecture map.
- Something went wrong: follow troubleshooting before cleaning state, retrying an effect, or widening authority.
Normative architecture: repository contract.