Configuration
How an organization tailors O2A through Configuration Artifacts, and why governed setup comes before live operation.
Configuration foundation
Configuration is the second of O2A's three layers: how an organization tailors the shared standard to its own structure. It is organized into Configuration Artifacts — each a governed setup unit that defines one category of organizational choice. One artifact records the unit types the organization uses, another the customers and needs it serves, another the natures of its offerings, and so on. Every artifact carries a semantic identifier in the CA-XXXXXX form — for example CA-UNITYP (unit types), CA-CUSNED (customers and needs), CA-OFFNAT (offering natures). The standard defines what each artifact is for; the values inside it belong to one organization.
How It Works
A Configuration Artifact governs one setup concern and moves through a governance lifecycle: Draft (authored content that does not yet govern), Validated (part of the governing basis, available to dependents), and Iterated (refinement of an artifact that was already governing). Authoring an artifact is the lifecycle, not a single act.
Configuration Artifacts depend on one another through a directed acyclic graph: some artifacts can only be authored once others are in place. Unlock is gated by state, not by existence — a dependent artifact becomes available only when its prerequisite is Validated. A Draft prerequisite unlocks nothing. The graph plus the state rule together fix the order in which setup can be authored.
Setting up an organization is therefore the act of instantiating the shared configuration grammar one artifact at a time, in the order the dependencies allow. Runtime operational data — Nodes, Offerings, Contracts — only follows once that governing basis is in place, and runtime data never substitutes for missing configuration.
Statements
The statements below state each rule precisely.
- Configuration prepares an organization for operation.
- Configuration is organized into Configuration Artifacts.
- A Configuration Artifact governs one setup concern.
- A Configuration Artifact has a semantic identifier in the
CA-XXXXXXform. - A Configuration Artifact moves through Draft, Validated, and Iterated states.
- Configuration dependencies use Validated prerequisites.
- Organization setup instantiates the shared O2A configuration grammar.
- Runtime operational data follows after the governing configuration basis.
Why It Matters
Configuration belongs to the standard, not to an application, because the meaning of operational entities depends on it. A Node, Offering, or Contract is only well-defined once the configuration that makes it meaningful exists and has been validated. This "configuration before operations" rule is part of the domain model itself, which is why this foundation sits ahead of the entity and runtime pages: get the setup basis right and everything operational reads correctly.
Related
- Configuration overview — the catalog of Configuration Artifacts.
- Grammar — the common rules every artifact obeys.
- Dependencies — the validated unlock graph.
- Operational Readiness — the validated minimum that grants the right to operate.
- Configuration Artifact — the entity-side page.