Configuration Artifact
The governed setup unit that tailors O2A for one organization — identity, governance lifecycle, and the entity boundary.
Entity
A Configuration Artifact is one governed area through which an organization
tailors the generic O2A model to its own structure. Each has a semantic
CA-XXXXXX identifier, moves through a governance lifecycle, and can depend
on other Configuration Artifacts through a directed acyclic graph that gates
unlock on validated prerequisites. The standard defines the meta-model — what
can be configured and how — and an implementation realizes the specific
values for one organization.
How It Works
Each Configuration Artifact is one governed setup concern named with a
semantic CA-XXXXXX identifier — a mnemonic label, not an ordinal slot — and
carries its own governance lifecycle. Authoring is a lifecycle rather than a
one-shot act: a draft is authored content without governing authority,
validation makes the artifact part of the governing basis, and iteration
records refinement after the artifact has already been governing.
Artifacts connect through typed dependencies — prerequisites, references, or constraints — forming a directed acyclic graph. Unlock is gated by state, not existence: a downstream artifact becomes available only when its prerequisite basis is VALIDATED; a DRAFT prerequisite unlocks nothing.
Reusable contract-authoring mechanisms are intentionally out of this set: a Replicable Contract Format is governed by Contract semantics, not Configuration Artifact semantics, and does not appear in the configuration dependency model.
Statements
These statements fix what a Configuration Artifact is, how it is identified, and the boundaries around the configuration set.
Identity and grammar
- A Configuration Artifact governs one setup concern.
- A Configuration Artifact has a semantic identifier in the
CA-XXXXXXform. - A Configuration Artifact has a governance lifecycle.
- Configuration tailors O2A to one organization.
- Configuration prepares an organization for operation.
Dependencies and unlock
- A Configuration Artifact can depend on other Configuration Artifacts.
- Configuration Artifact dependencies can be prerequisites, references, or constraints.
- A Configuration Artifact dependency uses a Validated prerequisite.
- A downstream Configuration Artifact unlocks only on a VALIDATED prerequisite basis, never on DRAFT existence.
Boundary
- A Replicable Contract Format is governed by Contract semantics rather than Configuration Artifact semantics.
Operations
The governed operations on a Configuration Artifact.
Author and govern artifacts
- Draft Configuration Artifact — creates an artifact in DRAFT, authored content that does not yet govern.
- Validate Configuration Artifact — moves an artifact to VALIDATED, the unlock-bearing state where it becomes part of the governing basis.
- Iterate Configuration Artifact — records a refinement of an artifact that has already been governing.
Reuse setup chains
- Export Configuration Template — exports a dependency-closed setup chain, following the DAG so the full prerequisite closure travels with it.
- Import Configuration Template — merges a dependency-closed setup chain into a target organization, applying conflict handling where incoming and existing configuration overlap.
The operation-level statements:
- Draft Configuration Artifact creates a Draft Configuration Artifact.
- Validate Configuration Artifact moves a Configuration Artifact to Validated.
- Iterate Configuration Artifact moves a Configuration Artifact to Iterated.
- Export Configuration Template exports a dependency-closed setup chain.
- Import Configuration Template merges a dependency-closed setup chain.
- Export Configuration Template uses prerequisite closure.
- Import Configuration Template uses conflict handling.
Lifecycle
A Configuration Artifact moves through exactly three governance states: DRAFT, VALIDATED, and ITERATED. Initial authoring moves DRAFT to VALIDATED. Later refinement of an already-governing artifact moves VALIDATED to ITERATED, and once that refinement is accepted it returns ITERATED to VALIDATED. ITERATED remains a governing state — it signals historical refinement, not loss of authority — so VALIDATED is the single unlock-bearing authority and ITERATED is evidence of revision rather than a separate unlock class.
This governance lifecycle is deliberately distinct from the contract, milestone, offering-status, and node/unit (CA-UNILIF) lifecycles; it describes configuration authoring status only.
The lifecycle statements:
- A Configuration Artifact lifecycle includes Draft, Validated, and Iterated.
- A Draft Configuration Artifact can become Validated.
- A Validated Configuration Artifact can become Iterated.
- A Validated Configuration Artifact unlocks dependents.
- A Draft Configuration Artifact remains in authoring state.
- The Configuration Artifact lifecycle governs setup readiness.
Configuration
This page covers the Configuration Artifact entity itself — its identity, governance, and operations. The Configuration family carries the rest:
- Grammar — common rules every artifact obeys.
- Dependencies — the validated unlock graph.
- Operational Readiness — the validated minimum that grants an organization the right to operate.
- Configuration overview — the catalog of artifacts in this release.
Why It Matters
Configuration precedes operations in O2A. Nodes, Offerings, and Contracts only become meaningful once the governing setup exists, so the identity, lifecycle, and dependency rules of Configuration Artifacts are what make the rest of the model land correctly for any given organization. Getting these right keeps operational behavior anchored on confirmed setup; getting them wrong leaves downstream meaning floating.
Related
- Organization — the entity that Configuration Artifacts tailor O2A for.
- Node — an operational entity whose meaning depends on validated configuration.
- Offering — configured via CA-OFFNAT, a Configuration Artifact.
- Contract — where the Replicable Contract Format is governed instead.