The goal of Open Application Model is to define a standard, runtime-agnostic way to describe application deployment across hybrid environments, clouds or even edge devices.

The central problem this specification seeks to address is how distributed applications can be composed and then successfully handed off to those responsible for operating them. The problem is not so much about how to write programs, but how to take components of a service oriented (or microservice oriented) architecture, and streamline the workflow that surrounds such applications.

This specification provides a description of such applications, where the description is declarative, extensible and with best clarity. Furthermore, it suggests patterns and processes for managing such applications. The specification describes a model for cloud native (i.e. highly distributed) applications, encompassing public cloud technologies, on-prem solutions, and IoT/edge technologies. By specifying a common model, this specification provides a foundation for building application delivery systems with a standard yet higher level description of cloud native applications.

- Defining or prescribing specific orchestrating workflow.

- Describing or defining the runtimes themselves.

This specification proposes a model that defines cloud native applications as follows:

| `apiVersion` | `string` | Y | | A string that identifies the version of the schema the object should have. The core types uses `core.oam.dev/v1beta1` in this version of specification |

This section declares the schematic of a component that could be instantiated as part of an application in the later deployment workflow. Note that OAM specification has no enforcement on how to implement the schematic as long as it could:

| `apiVersion` | `string` | Y | | A string that identifies the version of the schema the object should have. The core types uses `core.oam.dev/v1beta1` in this version of specification |

| `apiVersion` | `string` | Y || A string that identifies the version of the schema the object should have. The core types uses `core.oam.dev/v1beta1` in this version of specification. |

| `apiVersion` | `string` | Y || A string that identifies the version of the schema the object should have. The core types uses `core.oam.dev/v1beta1` in this version of specification. |

The _traits system_ is defined in this specification as the way a runtime applies and manages operational behaviors to instances of components through traits.

Runtime implementations of the specification MUST provide the traits system for attaching operational behaviors to instances of components.

- **Core traits.** This specification defines a set of trait definitions with type names in the `core.oam.dev` group. These traits provide operational functionality that is necessary for the operation of certain workload types and component features. Runtimes are REQUIRED to implement these traits as defined in this specification.

- **Standard traits.** The specification defines a set of trait definitions with type names in the `standard.oam.dev` group. These traits provide operational functionality that is commonly used by application operators and implemented by most runtimes. Runtimes are RECOMMENDED to use the standard trait definitions as defined in this specification when providing equivalent operational functionality to those listed in the standard trait definitions. In other words, if a runtime is implementing trait with behavior `foo` and a standard trait definition for behavior `foo` exists, the runtime SHOULD use the standard `foo` trait definition. Application operators that intend to maximize portability of their applications should use these trait definitions when available. Although this does not _guarantee_ portability of an application, it is designed to increase portability across runtimes.

- **Extension traits.** The specification allows a runtime to define its own set of trait definitions that are unique to that runtime in addition to those defined by core and standard traits. A runtime can choose to implement any set of traits in this category with any definition. Extension trait type names MUST NOT be in the `core.oam.dev` or `standard.oam.dev` groups.

The specification does not set requirements about how simple or complicated a trait may be. Some might expose an expansive set of configurable options while others may expose no configurable options. And it is not required that a trait be as exhaustive as its underlying technology. For example, an implementation of an autoscaling technology may provide numerous ways of determining when a component should scale. But the trait may only surface a few of those. Likewise, multiple autoscaling traits may be defined (each uniquely named), where each trait exposes a different subset of configurable options. Or one large trait may expose all of the possible autoscaling configurations.

Implementations of an OAM runtime SHOULD make all supported traits discoverable in the format explained below.

| `apiVersion` | `string` | Y || A string that identifies the version of the schema the object should have. The core types uses `core.oam.dev/v1beta1` in this version of specification. |

The specification is currently in Rough Draft, working toward Working Draft. After Working Draft, the specification will become a Final Specification (e.g., 1.0).

- During _Rough Draft_, no part of the specification is considered stable

- During _Final Specification_, the specification will only be updated with errata, grammatical fixes, and clearly marked "clarifying text"

The media types for schematics will be defined when the specification enters Working Draft status. Preliminarily, the media types will be of the form:

This specification, in its current form, does not mandate a specific set of security policies. However, it does provide guidance on certain aspects of security:

Other security details, such as network transport security or securing data at rest, are considered beyond the scope of this specification.

The Open Application Model follows a set of design principles that ensure the clarity, richness, and extensibility of the specification.

The specification as a whole is designed to provide application "distributions" where the same application can be executed on different platforms without alteration. This portability of the application is intended to make the following scenarios not just possible, but easy: