Skip to content

Config-as-Data / Application Config Register

Application configuration becomes stewarded data with approval and history so runtime systems read flags safely.

Why this is needed

  • Nobody knows who enabled an experiment in production.
  • Config in code requires redeploys for business toggles.
  • Audit needs a trail of flag changes.

Proposed entities in EntiHub

Governance settings

Setting Recommended value Why
approvalRequired true Prod flag changes need approval.
historyEnabled true Rollback via history/time-travel patterns.
allowSameAuthorApproval false Maker/checker separation for sensitive changes.
deletedRetentionDays 90 (or higher) Soft-delete retention for auditability.

Entity definition (YAML sketch)

name: app_config
displayName: App config
domain: Platform
description: App config
version: "1.0.0"
approvalRequired: true
historyEnabled: true
deletedRetentionDays: 90
displayRefColumn: config_key
uniqueConstraints:
  - name: uq_app_config_0
    columns: [config_key, environment]
columns:
  - name: config_key
    dataType: string
    nullable: false
    maxLength: 128
  - name: config_value
    dataType: string
    nullable: false
    maxLength: 2000
  - name: environment
    dataType: string
    nullable: false
    maxLength: 16
  - name: owner_team
    dataType: string
    nullable: false
    maxLength: 128
  - name: status
    dataType: string
    nullable: false
    maxLength: 16

YAML sketches

Sketches highlight the important fields and governance flags. Trim or extend columns to match your domain. See Setup Entity for the full YAML reference.

Sample data

config_key config_value environment owner_team status
feature.new_checkout true prod Digital active
partner.routing.map REGION=EU:P1 prod Integration active

Benefits for the company

  • Change flags without redeploy.
  • Audit who toggled production behavior.
  • Same API/CLI surface as other governed data.