← Back to catalogue
Published

Software Configuration

vr.wm-sft-011 · wm-sft-011-software-configuration

Describe a governed software configuration and its revisions, desired settings, references and version scope, with evidence of validation and adoption.

World Models Information and virtual systems INF.SFT.CFG
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

3 bundles · 3 layers · 5 findings · 10 questions

Scope What the configuration applies to.

Target and environment

The software, version range and environment the configuration targets.

Configuration target

The software component, version range and environment the settings apply to.

  1. Which software and versions does this configuration apply to?
  2. For which environment, such as test or production, is it meant?
Content What the configuration sets.

Settings and references

Values, feature flags and references to secrets and other resources.

Settings

The keys and values set, with their defaults and allowed ranges.

  1. Which settings are changed from their defaults?
  2. Does every value conform to the declared schema?

Secret references

References to secrets held in a secret store, never the secrets themselves.

  1. Which secrets does the configuration reference, and in which store?
  2. Are any secret values stored in plain text in the configuration?
Change control How the configuration changes over time.

Versions and drift

Versions, approvals and comparison with the running state.

Configuration version

The version of the configuration with its author, approval and change reason.

  1. Which version is current, and who approved it?
  2. What changed compared with the previous version, and why?

Drift

Differences between the declared configuration and what is actually running.

  1. Does the running system match the declared configuration?
  2. Which differences were found, and are they intended?

Classifiers Filled

Family
World Models
Category
Information and virtual systems
Entry kind
entity
Navigation path
NAV.INF.SFT.CFG
Domain
INF.SFT.CFG
Industry
Cross-industry
Tags
softwareconfigurationinf.sft.cfg

What it is Filled

A software configuration is the declared set of settings, references and version scope that tells a piece of software how to behave in a given environment, such as configuration files, feature flags, parameters and secret references. It is the desired state an operator intends; the running deployment and the code itself are separate records.

In scope

  • Configuration identity, target/version/environment scope and typed setting declarations
  • Resolution provenance, external resource and secret references, and optional dynamic flag bindings
  • Revision lineage, approval and validation references, consumption expectations, drift assessment and retirement of configuration records

Out of scope

  • Software source, package, release, deployment, runtime and telemetry master records
  • Secret payload storage, secret retrieval, credential rotation and permission grants
  • Production changes, remote evaluation, rollout execution, runtime remediation and automatic rollback
  • A universal configuration management database, executable template language or full security baseline catalogue

Why it exists Filled

Describe a governed software configuration and its revisions, desired settings, references and version scope, with evidence of validation and adoption.

Distinguishing features Filled

  • It is the declared desired state; the deployment is the act and record of applying it.
  • It is data that steers behaviour, kept separate from the source code of the software.
  • Secrets are referenced, not contained, in a well-formed configuration.
  • A configuration item in IT service management is a managed thing; a software configuration is the settings of one.

What robots and AI may and may not do Filled

Must not

  • Apply configuration changes to production without the required approval.
  • Read or reveal secret values through configuration references.
  • Disable security or audit settings.
  • Edit a configuration in place without keeping its previous version.
  • Copy production configuration with secrets into lower environments.

Only with a human decision

  • Approving production configuration changes.
  • Changing security, access or data retention settings.
  • Rotating or granting access to secrets.

May

  • Read configurations and validate them against their schema.
  • Compare declared configuration with running state and report drift.
  • Propose configuration changes as reviewable versions.
  • Flag secrets stored in plain text.

Moral aspects Filled

  • Misconfiguration is a frequent cause of data breaches that harm the people whose data is exposed.
  • Feature flags can expose groups of users to untested behaviour without their knowledge.
  • Clear configuration history supports accountability after incidents.

Who is affected

  • Users of the software
  • Operators and developers
  • People whose data the software processes

Owners Filled

Steward

The team that operates the software and owns its configuration in each environment.

Roles

Configuration steward
Maintain identity, namespace and target scope
Configuration editor
Propose typed changes with provenance and exact base
Change approver
Review impact and authorize only the declared revision and scope
Evidence reviewer
Assess validation, freshness and drift limitations
Records custodian
Apply retention, access and approved disposal rules

Master systems

  • Version control repositories
  • Configuration management databases
  • Secret stores
  • Feature flag services

Links to other meta-models Filled

references

  • WM-SFT-002 - Identify the target system. Registry parent is reconciled as a target relationship, without inheriting application operations. Candidate binding requires an adopting profile and version pin.
  • WM-SFT-007 - Bind component identity and compatibility without owning package content. Candidate binding requires an adopting profile and version pin.
  • WM-SFT-008 - Pin release versions when needed; releases retain their own evidence and lifecycle. Candidate binding requires an adopting profile and version pin.
  • WM-SFT-009 - Link external application attempts, acknowledgements and failures; configuration never executes deployment. Candidate binding requires an adopting profile and version pin.
  • WM-SFT-010 - Bind independently mastered environments and target selectors. Candidate binding requires an adopting profile and version pin.
  • WM-SFT-013 - Link change proposals and authorization evidence; change workflow remains external. Candidate binding requires an adopting profile and version pin.
  • WM-SFT-015 - Link compatibility and behavior test results without executing tests here. Candidate binding requires an adopting profile and version pin.
  • WM-SFT-017 - Reference observed state with time, source and coverage; preserve telemetry master identity. Candidate binding requires an adopting profile and version pin.
  • External secret authority - Keep credentials outside this model; resolve bindings only under separately authorized processes. Candidate binding requires an adopting profile and version pin.
  • External feature evaluation service - Delegate flag evaluation and context processing; retain bindings and qualified result references only. Candidate binding requires an adopting profile and version pin.

aligned

  • JSON Schema Draft 2020-12 - Optional validation vocabulary alignment, not universal instance-schema conformance. Candidate binding requires an adopting profile and version pin.
  • RFC 8342 NMDA - Conceptual intended/operational separation only; no protocol conformance claimed. Candidate binding requires an adopting profile and version pin.

neighbor

  • WM-SFT-002 Software System / Business Application - Registry parent identifies the target domain. Configuration references a separately mastered system; the parent does not imply that configuration inherits its business lifecycle.
  • WM-SFT-007 Software Component / Package and WM-SFT-008 Build / Release - Version selectors and pinned release references constrain applicability. Configuration content is not executable code, a build or a release manifest.
  • WM-SFT-009 Deployment and WM-SFT-010 Runtime / Compute Environment - Deployment owns application attempts and runtime owns environment identity. A local approved revision cannot establish activation or full adoption.
  • WM-SFT-013 Software Change / Pull Request and WM-SFT-015 Test Case / Test Result - Reference change authorization and test evidence without copying workflow or test execution semantics into configuration.
  • WM-SFT-017 Telemetry / Operational Signal and external secret or flag services - Configuration stores scoped evidence links and protected bindings. Observation, secret lifecycle and flag evaluation retain separate authorities.

parent

  • WM-SFT-002

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • A configuration is identified by its repository path or key and its version or commit identifier.
  • The target is identified by software name, version and environment name.
  • Secret references use the identifiers of the secret store.

Direct properties not applicable Not applicable

Not applicable

The subject is an institutional or informational record, not a physical object with measurable properties.

Recognition optional Filled

  • A configuration is a structured set of keys and values for a named software and environment.
  • Often confused with the deployment record, the source code or a configuration item in a CMDB.

Capabilities and actions required Filled

  • Configurations can be validated, versioned, compared and rolled back.
  • Configurations can be applied by automation to reach the desired state.
  • Drift between declared and running state can be detected.

Hazards and failure modes required Filled

  • Outages from invalid or untested configuration changes.
  • Data exposure from insecure defaults or leaked secrets.
  • Silent drift that makes systems differ from their records.

Standards and interfaces required Filled

  • JSON Schema for validating configuration documents.
  • YAML and TOML as common configuration formats.
  • OpenFeature for feature flag evaluation.

Context of use required Filled

  • Used in software operations, infrastructure as code and continuous delivery.
  • Security baselines such as CIS Benchmarks define recommended configuration settings.

Sources Filled

  1. Guide for Security-Focused Configuration Management of Information Systems - National Institute of Standards and Technology
  2. ConfigMaps - Kubernetes project
  3. JSON Schema Validation: A Vocabulary for Structural Validation of JSON - JSON Schema project
  4. Network Configuration Protocol (NETCONF) - Internet Engineering Task Force
  5. Network Management Datastore Architecture (NMDA) - Internet Engineering Task Force
  6. Flag Evaluation API - OpenFeature project
  7. Secrets - Kubernetes project
  8. JavaScript Object Notation (JSON) Patch - Internet Engineering Task Force
  9. NIST SP 800-128 Guide for Security-Focused Configuration Management of Information Systems, NIST
  10. ISO/IEC/IEEE 828 Configuration management in systems and software engineering, ISO/IEC/IEEE

Open questions

  • Complete coordinator-side source checks and immutable document pins, then review supported claims and errata against the adopting versions.
  • Build instance profiles and fixtures for absent versus null values, duplicate keys, conflicting overlays, concurrent edits, mutable references, partial adoption, stale observations and lossy conversion.
  • Validate adopting authority, consumer capabilities and retention requirements, and restore independent external review before any canonical promotion.
  • Nested instance schemas, concrete resolver implementations and acceptance fixtures
  • Pinned adopting profiles, consumer-specific key catalogues and universal merge semantics
  • Independent external review and complete current-version source verification
  • Specialized regulated or safety-critical deployment assurance; requires separate qualified profiles

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-011-software-configuration/spec.yaml, ver-cy/world-models/card-supplements/wm-sft-011-software-configuration.json