← Back to catalogue
Published

Configuration Record

vr.wm-rec-014 · wm-rec-014-configuration-record

Preserve a versioned declaration of intended configuration with identity, applicability and accountable evidence, distinct from observed runtime state.

World Models Information and virtual systems INF.REC.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 · 4 findings · 9 questions

Declared configuration What the configuration says.

Configuration version

One version of the declared settings for a target.

Target and version

The system the record configures and the version identifier.

  1. Which system, device or service does this record configure?
  2. Which version of the record is this, and which version did it replace?

Settings and secrets

The parameters and how secrets are referenced.

  1. Which parameters does the version set, and against which schema?
  2. Are secrets referenced from a secret store rather than written in the record?
Change control How the configuration changes.

Change history

Who changed what, when and with whose approval.

Change record

Author, approval and reason for a change.

  1. Who authored the change, and who approved it?
  2. Which change request or incident is the change linked to?
Drift Whether the running system matches the declaration.

Declared versus runtime

Comparison between the record and observed state.

Drift finding

A difference between declared and runtime configuration.

  1. Does the running system match the declared version?
  2. Which settings differ, and was the difference authorized?
  3. Was the drift corrected by redeploying the record or by updating it?

Classifiers Filled

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

What it is Filled

A configuration record is a versioned statement of how a system, device or service is meant to be set up: its parameters, components and settings as declared by its owner. It is the declared or desired configuration, kept distinct from the runtime state observed on the running system, and every change produces a new version. Logs, telemetry and the source code of the system are separate subjects.

In scope

  • Stable record identity, revision identity and target applicability binding
  • Declared content references, schema binding and transformation lineage
  • Change and approval references, validation evidence and scoped designations
  • External application and comparison evidence links, disclosure, integrity and retention

Out of scope

  • Software parameter definitions and executable configuration engines
  • Target asset, software product, service or sellable product-variant master lifecycle
  • Runtime telemetry collection, drift evaluator, deployment, rollback execution and security enforcement
  • Secret-store lifecycle, legal authorization and universal sector compliance
  • Generic records-management or audit-event engine implementation

Why it exists Filled

Preserve a versioned declaration of intended configuration with identity, applicability and accountable evidence, distinct from observed runtime state.

Distinguishing features Filled

  • Declares the intended configuration, distinct from the runtime state observed on the system.
  • Every change creates a new version with author and approval, so past states can be restored.
  • Distinct from a document record in general, its parent, because it is machine-applied to a target.
  • Distinct from logs and telemetry, which describe what happened, not what was intended.

What robots and AI may and may not do Filled

Must not

  • Apply configuration changes to production without the required approval.
  • Write secrets in plain text into configuration records.
  • Overwrite or delete history so that past versions cannot be restored.
  • Disable security settings, logging or monitoring through configuration changes.
  • Silently correct drift without recording what was changed.

Only with a human decision

  • Approving changes to production or safety-related configuration.
  • Rolling back a configuration during an incident.
  • Granting new access rights through configuration.

May

  • Read configuration records and explain what they set.
  • Compare declared and runtime configuration and report drift.
  • Propose configuration changes as new versions for review.
  • Validate records against their schema and policies.

Moral aspects Filled

  • Misconfiguration is a leading cause of outages and data breaches that harm users.
  • Configuration of safety-related systems can affect physical safety.
  • Accountability requires knowing who changed what and why.

Who is affected

  • Users of the configured systems
  • Operators and engineers
  • People whose data the systems process

Owners Filled

Steward

The team that operates the configured system owns its configuration records and their change history.

Roles

Record custodian
Maintain master identity, revision lineage and retention bindings
Declaration author
Propose scoped changes and explain unresolved values
Approving authority
Decide permitted use for exact revisions and scopes under adopting policy
Evidence reviewer
Assess source, coverage and qualification of validation and use evidence
Access steward
Govern disclosure, secret references and incident restriction

Master systems

  • Version control repositories
  • Configuration management databases
  • Configuration management tools

Links to other meta-models Filled

extends

  • WM-REC-001 - Candidate specialization of governed records; pin the generic identity and custody contract before implementation. No mandatory runtime dependency asserted.

references

  • WM-SFT-011 - Optional software-specific configuration semantics and revision scope; do not duplicate its domain model.
  • WM-REC-013 - Optional external application and observation event evidence; preserve the log master.
  • WM-OBJ-017 - Optional configured product variant target; do not absorb variant definition or feasibility rules.

aligned

  • RFC 8342 - Conceptual stage distinction for network profiles; not every record uses these datastores.
  • PROV-O - Proposed derivation, revision and attribution crosswalk; no tested RDF conformance claimed.
  • JSON Schema Draft 2020-12 - Optional schema-resource and dialect binding for a JSON projection; complete nested schemas remain deferred.

neighbor

  • WM-REC-001 Document / Record - Registry parent is a conceptual specialization candidate. Reuse its generic record contract through a pinned adopting profile; this model specializes declaration-specific context and does not implement a second generic record engine.
  • WM-SFT-011 Software Configuration - That sibling owns software-specific desired settings and version scope. This record attests to a declaration revision and can reference those semantics; a record revision is not automatically a software release.
  • WM-REC-013 Operational Log / Trace - Events and observations remain separately mastered evidence. Application receipts and comparison reports are links, not a runtime state master.
  • WM-OBJ-017 Product Configuration / Variant - A sellable product variant is not this governed declaration. A target or variant reference does not transfer product-family constraints into this record.
  • Deployment and target operations - Record designation, syntactic validity and stored approval do not execute, authorize or prove successful target mutation. External operators own application and restoration.

parent

  • WM-REC-001

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • A record is identified by its target, its path or key in the repository and a version or commit identifier.
  • Configuration items in a configuration management database carry their own item identifiers.

Direct properties not applicable Not applicable

Not applicable

A configuration record is an information record, not a physical object with measurable physical properties.

Recognition optional Filled

  • A structured file or entry of settings with a target, a version and a change history.
  • Often confused with runtime state, application data or deployment logs.

Capabilities and actions required Filled

  • Records can be versioned, reviewed, applied, compared and rolled back.
  • Policies can validate a record before it is applied.

Hazards and failure modes required Filled

  • A faulty change taking down a service or exposing data.
  • Secrets leaked through configuration files.
  • Unrecorded drift that hides unauthorized changes.

Standards and interfaces required Filled

  • Git and other version control systems for history and review.
  • YAML, JSON and TOML with schemas such as JSON Schema.
  • ITIL service configuration management and ISO/IEC 20000-1 for configuration control.

Context of use required Filled

  • Used in IT operations, cloud infrastructure, network devices and industrial control.
  • Change control is required by security and service management standards.

Sources Filled

  1. RFC 8342: Network Management Datastore Architecture (NMDA) - IETF
  2. RFC 6241: Network Configuration Protocol (NETCONF) - IETF
  3. RFC 6902: JavaScript Object Notation (JSON) Patch - IETF
  4. PROV-O: The PROV Ontology - W3C
  5. Guide for Security-Focused Configuration Management of Information Systems, NIST SP 800-128 - NIST
  6. JSON Schema: A Media Type for Describing JSON Documents - JSON Schema project
  7. RFC 8785: JSON Canonicalization Scheme (JCS) - IETF
  8. ISO/IEC 20000-1 Service management system requirements, ISO/IEC
  9. NIST SP 800-128 Guide for Security-Focused Configuration Management of Information Systems, NIST
  10. ISO 10007 Guidelines for configuration management, International Organization for Standardization

Open questions

  • Run the deferred direct HTTP checker and review source update chains, errata, licensing and profile applicability without equating reachability with claim verification.
  • Pin neighbor contracts and develop nested schemas and fixtures for concurrent writes, failed patch tests, unresolved dependencies, rotating secrets, partial application, stale observations and lossy projections.
  • Review physical-device, manual and sector-specific authority, retention and confidentiality profiles, and restore independent external review before canonical promotion.
  • Independent external review remains absent under the owner-authorized provider waiver.
  • Direct HTTP status is unmeasured in this sandbox; live version, errata and update-chain review is incomplete.
  • Executable nested instance schemas, pinned neighbor contracts, transformation and comparison mappings and adversarial fixtures remain incomplete.
  • Sector-specific physical equipment, offline/manual procedures, jurisdiction, retention schedules and licensing need adopting-profile review.

Machine files

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

Provenance

world-models research · reviewable-draft

Built from: models/wm-rec-014-configuration-record/spec.yaml, ver-cy/world-models/card-supplements/wm-rec-014-configuration-record.json