Configuration as a Product

Från installationsfil till produktkontrakt

Konfiguration behandlas ofta som en biprodukt av installationen: några filer, manuella steg och kunskap hos den konsult som senast gjorde ändringen. Det fungerar tills flera kunder, produktversioner, scenarier och miljöer ska utvecklas parallellt.

Configuration as a Product innebär att önskat läge får identitet, version, schema, ägare, provenance, compatibility, review, test, release och livscykel. Konfigurationen är inte bara input till deployment. Den är den granskningsbara bärare som förklarar vad en lösning består av och vad en ändring innebär.

Sex tillstånd

En robust modell skiljer:

1. standard eller scenario,
2. kund-/miljöspecifika parametrar,
3. effektiv konfiguration efter overlays och overrides,
4. genererad konfiguration,
5. applicerad konfiguration,
6. observerad konfiguration.

Skillnaden mellan genererad och observerad konfiguration är drift. Skillnaden mellan standard och effektiv konfiguration förklarar kundens avvikelse. Skillnaden mellan två releaseartefakter förklarar förändringen. Dessa relationer måste beräknas från explicit precedence, inte filordning eller senaste skribent (CLAIM-CONFIG-001, CLAIM-CONFIG-002).

Scenarioportföljen

En verklig kundlösning består sällan av ett enda scenario. Ett xECM- workspace kan dela kategori med ett ärendescenario, få roller från Entra och vara beroende av en recordsklass. Därför behöver en framtida ConfigurationRelease binda:

• valda scenarier och exakta versioner,
• parametrar, overlays och beslutade overrides,
• normaliserade objektidentiteter,
• ägarskap och referenser,
• generator- och schemarevisioner,
• outputdigests och source maps,
• plan och expected population,
• verifierings- och rollbackkontrakt.

Interaktioner ska klassas som ägarskap, referens, delad resurs, konflikt, ordningskrav eller unknown. Zero silent skip är viktigare än en vacker graf.

Den landade F39-kedjan

Generators main innehåller en konkret kedja för scenarioarbete:

profil → deterministisk data → content manifest → entityprojektion
       → blueprint → apply-plan/dry-run → playbook → planerad miljögraf

NIS-scenariot har ett dry-run-bevis med 1 760/1 760 blueprintobjekt och 1 295 planoperationer, utan saknade eller oväntade objekt. Det är ett starkt expected-population-bevis för planen (CLAIM-ACTION-011).

Begränsningarna är lika viktiga:

• blueprintens informationsarkitektur är manuellt författad,
• entityvärden projiceras automatiskt men hela IA:n syntetiseras inte,
• LLM-genererad dokumentkropp är inte byte-deterministisk,
• dry-run bevisar ingen extern effekt,
• planerad miljögraf är inte observerad miljö,
• generell scenarioportfölj och selektiv rollback är ännu målkontrakt.

Läsbar JSON utan att förstöra källan

Användaren behöver se rå JSON, söka, jämföra och förstå strukturen i exempelvis xECM. Men genererad output får inte bli en ny, handredigerad sanningskälla. En ändring ska flyttas till rätt nivå:

• scenario om den gäller alla konsumenter,
• parameter om den är en typad variation,
• overlay om den hör till kund eller miljö,
• tidsbundet override om avvikelsen kräver beslut.

Design Studio bör visa source map från varje effektivt fält och objekt tillbaka till denna källa. Saknad source map är ett produktgap, inte en anledning att låta användaren skriva över generatorresultatet.

Preview, apply och verification

En preview har effect=none. En apply är ett försök mot ett explicit target. Ett receipt visar vad adaptern säger att den gjorde. Verifiering läser tillbaka via en oberoende väg och jämför hela expected population (CLAIM-CONFIG-004, CLAIM-CONFIG-005).

Livscykeln bör vara:

draft → validated → reviewed → approved → planned
      → applying → applied → observed → verified | deviated | unknown

Varje övergång behöver actor, revision, policybeslut, tid och evidens.

Rollback är ny förändring

En gammal fil är inte automatiskt ett säkert återställningskommando. Andra scenarier kan ha ändrats, externa objekt kan ha skapats och data kan ha konsumerats. Rollback ska därför skapa ett nytt intent mot aktuell observation, räkna om beroenden och använda kompensation när en sann invers saknas (CLAIM-ACTION-005).

En selektiv rollback behöver visa:

• vald enhet: override, scenario, release eller objektmängd,
• direkt och indirekt påverkan,
• delade objekt och ordningskrav,
• irreversibla dataeffekter,
• ny desired revision,
• postconditions och read-back.

Produktkonsekvens

Design Studio bör inte vara ett stort YAML-formulär. Det bör erbjuda fyra sammanhängande projektioner av samma versionerade modell:

• semantisk struktur för mänsklig förståelse,
• rå JSON för precision,
• relationer och scenariointeraktioner,
• diff mellan standard, effektiv, genererad och observerad konfiguration.

Det kommersiella värdet ligger i parallellitet och återanvändning: flera scenarier kan utvecklas, jämföras och granskas utan att deras output eller effekt blandas samman. När exakt konfiguration är deploybaren blir även rollback, påverkan och kundsupport mer förklarbara.

Spårbarhet

CLAIM-CONFIG-001–CLAIM-CONFIG-005, CLAIM-ACTION-005, CLAIM-ACTION-011.

Visuella referenser

FIG-09-01 — Konfigurationens väg från deklaration till verifierad konvergens

FIG-10-01 — Från handlingsförslag till verifierat eller reconcilerat utfall

SCREEN-09-01 — Design Studio med landad F39-kedja och markerad produktmålbild. Landad/dry-run-verifierad F39 blandas inte med konceptuell scenarioportfölj eller liveeffekt.