Part 007 — Catalog as a Runtime Source of Commercial Behavior

Positioning

Catalog dalam enterprise CPQ bukan hanya daftar nama produk dan harga.

Catalog dapat menjadi executable commercial model yang mengendalikan:

• discoverability;
• eligibility;
• configuration;
• validation;
• pricing;
• quote construction;
• order transformation;
• dan downstream interpretation.

Namun semakin banyak behavior dipindahkan ke catalog, semakin besar kebutuhan terhadap:

• governance;
• validation;
• versioning;
• testability;
• explainability;
• dan operational safety.

Core thesis: catalog-driven architecture meningkatkan product agility hanya jika metadata memiliki semantics yang eksplisit, lifecycle yang terkendali, dan runtime execution yang dapat diuji serta dijelaskan.

1. What Catalog-Driven Means

Catalog-driven berarti runtime behavior ditentukan sebagian oleh catalog metadata atau rules.

Contoh:

Offering exists in catalog
-> user can discover it
-> system knows required characteristics
-> constraints determine valid configuration
-> price definitions determine calculation
-> mapping determines order intent

Catalog menjadi input aktif bagi behavior sistem.

2. Catalog as Data versus Catalog as Behavior

Catalog as data

Menyimpan:

• names;
• descriptions;
• codes;
• display metadata.

Catalog as behavior

Menyimpan atau mereferensikan:

• rules;
• relationships;
• defaults;
• eligibility;
• prices;
• decomposition hints;
• and lifecycle policies.

Semakin dekat ke behavior, semakin tinggi risiko runtime misconfiguration.

3. Catalog-Driven Spectrum

Catalog-driven tidak binary.

Possible spectrum:

1. Display-only catalog.
2. Searchable commercial catalog.
3. Configurable product catalog.
4. Pricing-aware catalog.
5. Qualification-aware catalog.
6. Order transformation-aware catalog.
7. Fulfillment-template-aware catalog.
8. Fully metadata-driven commercial platform.

Setiap level menambah flexibility sekaligus governance burden.

4. Why Enterprises Prefer Catalog-Driven Models

Potential benefits:

• faster offer launch;
• less code deployment;
• reusable product structures;
• tenant/market variation;
• centralized commercial semantics;
• and consistent downstream interpretation.

5. Why Catalog-Driven Models Fail

Common causes:

• generic metadata without strong semantics;
• too many extension points;
• hidden rule precedence;
• untestable combinations;
• mutable published content;
• and direct production editing.

6. Catalog as a Product

Treat catalog capability itself as a product.

It needs:

• users;
• value;
• lifecycle;
• quality;
• observability;
• support;
• and roadmap.

Catalog tooling is not merely an admin screen.

7. Catalog Users

Potential users:

• product managers;
• catalog administrators;
• pricing managers;
• solution designers;
• integration teams;
• support;
• and operations.

Each needs different views and controls.

8. Catalog Responsibilities

Possible responsibilities:

• ProductSpecification;
• ProductOffering;
• characteristics;
• relationships;
• lifecycle;
• market/channel scope;
• price references;
• eligibility metadata;
• and decomposition metadata.

Do not assign all responsibilities by default.

9. Catalog Boundary

A catalog should own definitions.

It should not usually own:

• customer-specific quote state;
• approval decision;
• accepted price snapshot;
• order execution progress;
• or installed product state.

10. Catalog Runtime Contract

A runtime consumer should know:

Which catalog version?
Which publication?
Which market/tenant?
Which effective date?
Which schema version?
Which rule set?

11. Product Model as Metadata

Metadata may define:

• item types;
• characteristic types;
• cardinality;
• bundles;
• relationships;
• rules;
• and templates.

The runtime must interpret this metadata consistently.

12. Metadata Interpreter

A metadata interpreter converts definitions into behavior.

Responsibilities may include:

• type validation;
• defaulting;
• rule evaluation;
• UI schema generation;
• and transformation.

It is production code even if behavior comes from data.

13. Catalog-Driven UI

Catalog can drive:

• form fields;
• choices;
• dependencies;
• labels;
• and validation.

Benefits:

• rapid change.

Risks:

• generic UX;
• inaccessible forms;
• and difficult custom interactions.

14. UI Schema versus Domain Schema

A UI schema should not become the authoritative domain model.

Separate:

• display hints;
• domain constraints;
• and persistence semantics.

15. Catalog-Driven Configuration

Catalog may describe:

• available options;
• required selections;
• exclusions;
• defaults;
• and calculated characteristics.

The configuration engine evaluates them for context.

16. Catalog-Driven Validation

Validation rules may include:

• mandatory characteristics;
• range;
• dependency;
• cross-item constraints;
• and lifecycle restrictions.

Validation result should be explainable.

17. Catalog-Driven Pricing

Catalog may include:

• price definitions;
• rate cards;
• price components;
• eligibility;
• and adjustment references.

Pricing engine should own calculation semantics.

18. Catalog-Driven Qualification

Catalog may describe:

• market eligibility;
• channel availability;
• prerequisite product;
• segment restrictions;
• and serviceability hooks.

Avoid embedding external runtime facts directly into static catalog.

19. Catalog-Driven Quote Construction

Catalog can help determine:

• default item hierarchy;
• commercial grouping;
• document labels;
• and terms.

Quote should snapshot relevant result.

20. Catalog-Driven Order Transformation

Catalog may define mapping from:

• offering;
• configured product;
• and action

to:

• ProductOrderItem structure;
• service intent;
• or fulfillment template.

This is high-risk behavior and needs strong versioning.

21. Runtime Interpretation versus Compilation

Runtime interpretation

System reads catalog dynamically.

Benefits:

• immediate flexibility.

Risks:

• runtime cost;
• and production-only failures.

Compilation

Catalog is validated and transformed into optimized artifacts.

Benefits:

• performance;
• stronger validation.

Risks:

• publication complexity;
• and generated-artifact management.

22. Catalog Compilation Pipeline

Possible pipeline:

23. Draft Model

Draft content may be mutable.

It should support:

• collaboration;
• validation;
• comparison;
• and review.

Draft identity is different from published immutable version.

24. Publication Model

Publication freezes a coherent set of content.

It should include:

• version;
• scope;
• checksum;
• activation time;
• and release notes.

25. Activation Model

Publication and activation may differ.

Example:

• publish Friday;
• activate Monday.

This supports controlled release.

26. Immutable Published Catalog

Immutability improves:

• reproducibility;
• rollback;
• and historical quote consistency.

Corrections should usually create a new version.

27. Hotfixing Catalog

Emergency catalog change still needs:

• validation;
• audit;
• version;
• and rollback.

Direct database updates are unsafe.

28. Catalog Version

Version must identify a coherent semantic state.

Avoid versioning only individual rows without publication context.

29. Entity Version versus Publication Version

Entity version

Version of one offering/specification.

Publication version

Version of a complete deployable catalog set.

Both may be required.

30. Effective Dating

Catalog content can be:

• valid now;
• future-dated;
• expired;
• or retired.

Runtime selection should use business effective time.

31. Tenant and Market Scope

A catalog view may depend on:

• tenant;
• geography;
• brand;
• segment;
• channel;
• and contract.

Avoid duplicating full catalogs per tenant when overlay can suffice.

32. Catalog Overlay

Overlay allows tenant/customer variation over a base catalog.

Possible override:

• visibility;
• price;
• label;
• default;
• and relationship.

Need precedence and conflict policy.

33. Inheritance

Inheritance can reduce duplication.

Risks:

• hidden behavior;
• deep chains;
• and change propagation.

Prefer explicit composition where possible.

34. Rule Precedence

When multiple sources define behavior, precedence must be explicit.

Example:

Global baseline
< Market override
< Tenant override
< Contract override

35. Conflict Detection

Catalog publication should detect:

• contradictory rules;
• circular dependencies;
• duplicate identifiers;
• invalid dates;
• unreachable options;
• and broken references.

36. Reference Integrity

Every reference should be validated:

• offering to specification;
• bundle to child;
• price to offering;
• rule to characteristic;
• mapping to target.

37. Semantic Validation

Schema validation is not enough.

Semantic validation checks:

• meaningful combinations;
• lifecycle compatibility;
• and business invariants.

38. Static Rule Analysis

Possible checks:

• cycles;
• unreachable state;
• contradictory conditions;
• duplicate priority;
• and unbounded recursion.

39. Combinatorial Explosion

Complex product rules can create enormous configuration space.

Mitigations:

• partition rules;
• constrain scope;
• use decision tables;
• incremental evaluation;
• and representative scenario testing.

40. Catalog Test Pyramid

Possible layers:

• schema validation;
• unit tests for rules;
• scenario tests;
• golden configurations;
• pricing regression;
• quote generation;
• order transformation;
• and production smoke tests.

41. Golden Scenarios

Golden scenarios represent critical customer journeys.

Example:

Tenant A
Market ID
Offering Premium
20 sites
24-month term
Expected bundle, price, approval route, and order mapping

42. Catalog Contract Test

Validate that consumers can interpret:

• structure;
• enums;
• required fields;
• and semantics.

43. Publication Test

Test the publication as a whole, not only individual entities.

44. Backward Compatibility

Catalog evolution may affect:

• open configuration sessions;
• draft quotes;
• accepted quotes;
• orders;
• and inventory.

Define compatibility per lifecycle.

45. Open Draft Handling

Options:

• pin to original catalog;
• migrate;
• refresh on demand;
• or invalidate.

Each needs user experience and audit.

46. Accepted Quote Handling

Accepted quote should generally preserve:

• selected definition;
• price;
• terms;
• and version.

Do not silently rebind to new catalog.

47. In-Flight Order Handling

Order should preserve mapping/version used for conversion.

New catalog version should not alter execution unexpectedly.

48. Inventory Compatibility

Existing installed product may reference retired catalog entities.

Retirement must not destroy historical resolution.

49. Deprecation

A catalog entity may be:

• deprecated;
• no longer sellable;
• still orderable for amendment;
• still visible for support;
• or fully retired.

Use explicit lifecycle.

50. Supersession

Supersession links old offering to replacement.

It should not automatically migrate customer intent.

51. Upgrade Path

Upgrade path may define:

• eligible source;
• target;
• migration rule;
• price impact;
• and effective date.

52. Rollback

Catalog rollback may mean:

• activate prior publication;
• disable current version;
• or publish corrective version.

Need to account for transactions already created.

53. Feature Flags and Catalog

A flag can gate:

• offering visibility;
• rule activation;
• and mapping.

Risks:

• multiple control planes;
• and hard-to-reproduce behavior.

Store flag state/provenance when it affects commercial output.

54. Catalog and Caching

Catalog is read-heavy.

Caching may occur:

• client;
• gateway;
• service;
• engine;
• and database.

Need version-aware keys.

55. Cache Invalidation

Use:

• publication ID;
• event;
• time;
• or explicit purge.

Avoid cache keyed only by offering ID when version matters.

56. Catalog Search

Search should account for:

• market;
• tenant;
• channel;
• effective date;
• eligibility;
• and visibility.

Search result is not final qualification.

57. Catalog Projection

Search index is a projection.

It may be temporarily stale.

Do not use it as authority for order conversion.

58. Catalog API

Possible API groups:

• design-time administration;
• runtime query;
• publication;
• validation;
• and event subscription.

Separate write/admin from runtime read contracts.

59. Runtime Query Contract

A runtime query may need:

tenant
market
channel
effectiveAt
catalogPublication
language
customerContext

60. Catalog Event

Representative events:

• CatalogPublicationCreated;
• CatalogPublicationActivated;
• OfferingDeprecated;
• PriceDefinitionUpdated.

Events should be versioned and stable.

61. Catalog Event Consumer

Consumers may:

• invalidate cache;
• rebuild index;
• prepare pricing;
• and update analytics.

They should handle replay and duplicates.

62. Catalog Governance

Governance should define:

• who can edit;
• who reviews;
• who publishes;
• who activates;
• and who can rollback.

63. Separation of Duties

Possible policy:

• author cannot activate own high-risk publication;
• pricing and product changes reviewed separately;
• emergency override audited.

64. Change Classification

Classify changes:

• display-only;
• additive;
• behavioral;
• pricing;
• breaking;
• and fulfillment-affecting.

Review depth should match risk.

65. Catalog Diff

A useful diff should show semantic changes:

• offering added/removed;
• characteristic changed;
• rule changed;
• price changed;
• relationship changed;
• effective date changed.

Raw JSON diff is insufficient.

66. Impact Analysis

Before publication, identify:

• affected offers;
• active drafts;
• open quotes;
• order mappings;
• tenants;
• and downstream consumers.

67. Blast Radius

Catalog misconfiguration can affect:

• all sales users;
• one market;
• one tenant;
• one offering;
• or one channel.

Scope controls reduce blast radius.

68. Pilot Activation

Use pilot by:

• tenant;
• market;
• user group;
• or channel.

Need rollback and monitoring.

69. Observability

Monitor:

• publication success;
• cache version;
• rule failures;
• invalid configurations;
• pricing errors;
• transformation errors;
• and catalog lookup latency.

70. Business Observability

Useful signals:

• offering selection rate;
• invalid configuration rate;
• stale quote count;
• rule conflict count;
• and order fallout by catalog version.

71. Catalog Incident

Examples:

• offering disappears;
• wrong price activated;
• impossible bundle;
• broken order mapping;
• cross-tenant visibility.

Need incident classification and rollback.

72. Catalog Reconciliation

Compare:

• authoritative catalog;
• runtime artifact;
• search index;
• cache;
• and downstream mappings.

73. Catalog Repair

Use:

• republish;
• recompile;
• invalidate;
• or corrective version.

Avoid direct mutation of runtime artifact.

74. Catalog Ownership

Possible split:

• Product owns semantics.
• Catalog team owns platform.
• Pricing owns price policy.
• Engineering owns runtime interpreter.
• Operations owns availability.

Clarify boundaries.

75. Catalog Platform Team

A platform team should provide:

• self-service;
• validation;
• publication safety;
• observability;
• and documentation.

It should not own every product decision.

76. Product Team

Product team owns:

• value;
• offering lifecycle;
• and customer relevance.

They need safe tools, not unrestricted production access.

77. Engineering Team

Engineering owns:

• interpreter correctness;
• contracts;
• performance;
• and operational reliability.

78. Data Team

May support:

• analytics;
• quality;
• and lineage.

It should not redefine commercial semantics independently.

79. Catalog-Driven Architecture Smells

• everything configurable;
• generic key/value metadata;
• no publication boundary;
• rules edited directly in production;
• no semantic diff;
• no golden scenarios;
• no owner for runtime failures;
• and impossible rollback.

80. Over-Configuration

When every behavior becomes configuration:

• semantics weaken;
• testing becomes difficult;
• and product change may become less safe than code change.

81. Under-Configuration

When every product variation requires code:

• lead time grows;
• customer forks appear;
• and catalog loses value.

82. Stringly Typed Metadata

Example:

{
  "type": "NUMBER",
  "value": "100",
  "unit": "Mbps"
}

Without strong schema and validation, runtime failures increase.

83. Generic Rule DSL Risk

A powerful DSL may become:

• hard to debug;
• inaccessible to product users;
• and unsafe under version evolution.

Use constrained domain language.

84. Hidden Defaults

Defaults should be:

• visible;
• sourced;
• and overridable by policy.

Hidden defaults create surprising commercial outcomes.

85. Side-Effectful Rule

Catalog rules should ideally be deterministic.

A rule that calls external systems or mutates state is difficult to test and reproduce.

86. Runtime External Dependency

If catalog evaluation depends on external data:

• separate static definition;
• dynamic context;
• and fallback.

87. Explainability

For any outcome, explain:

Which offering?
Which publication?
Which rules?
Which context?
Which defaults?
Which overrides?

88. Reproducibility

Given same:

• publication;
• context;
• inputs;
• and engine version,

the output should be reproducible.

89. Determinism

Non-deterministic behavior from:

• unordered rules;
• current time;
• random IDs;
• or external mutable data

must be controlled.

90. Engine Version

The runtime engine version can affect interpretation.

Preserve it for critical historical calculation or transformation.

91. Catalog Migration

When metadata schema changes:

• support old and new versions;
• migrate drafts;
• rebuild artifacts;
• and test consumers.

92. Schema Registry

A registry can manage:

• metadata schema;
• version;
• compatibility;
• and validation.

93. Catalog as Code

Catalog-as-code stores definitions in version control.

Benefits:

• review;
• diff;
• CI;
• and reproducibility.

Risks:

• poor business-user experience;
• and slower non-technical changes.

94. Catalog as Managed Data

Admin tooling supports business users.

Need equivalent:

• review;
• version;
• diff;
• and CI-like validation.

95. Hybrid Authoring

Possible model:

• UI authoring;
• export to versioned artifact;
• automated validation;
• controlled publication.

96. Environment Promotion

Promote catalog across:

• development;
• test;
• staging;
• production.

Avoid re-entering content manually per environment.

97. Environment-Specific Data

Separate:

• semantic catalog;
• environment endpoint;
• secret;
• and deployment config.

Do not bake infrastructure details into commercial definition.

98. Worked Example: New Premium Offer

Change

Create Premium Connectivity offering.

Catalog content

• specification reference;
• bandwidth options;
• premium support;
• 24/36-month terms;
• eligibility;
• price references;
• order mapping.

Pipeline

• draft;
• semantic validation;
• scenario tests;
• pilot tenant;
• activate;
• monitor.

99. Worked Example: Broken Bundle

A bundle requires:

• Managed Router.

But excludes:

• all router options.

Publication validation should detect unsatisfiable configuration before production.

100. Worked Example: Price Change

Base recurring price changes next month.

Need:

• future-dated price version;
• existing quote policy;
• accepted quote preservation;
• and pricing cache invalidation.

101. Worked Example: Retired Offering

Offering is no longer sellable.

But:

• existing customers may modify;
• support must see it;
• inventory must resolve it;
• and billing must continue.

Retired is not deleted.

102. Worked Example: Tenant Overlay

Base catalog allows 100/500/1000 Mbps.

Tenant overlay:

• hides 100 Mbps;
• changes label;
• adds contract-specific price.

Need:

• precedence;
• scope;
• and conflict validation.

103. Worked Example: Mapping Drift

Catalog mapping changed after quote acceptance.

Order conversion must use:

• version pinned at accepted quote,
• or explicit approved migration policy.

Do not use current mapping silently.

104. Catalog Publication Checklist

## Scope

- [ ] Tenant/market/channel defined.
- [ ] Effective dates defined.

## Semantics

- [ ] References resolve.
- [ ] Rules are satisfiable.
- [ ] Defaults and overrides are explicit.

## Compatibility

- [ ] Draft/open quote impact reviewed.
- [ ] Order mapping compatibility reviewed.

## Evidence

- [ ] Golden scenarios pass.
- [ ] Pricing regression passes.
- [ ] Transformation tests pass.

## Operations

- [ ] Pilot/rollout defined.
- [ ] Monitoring ready.
- [ ] Rollback path defined.

105. Catalog Entity Template

## Identity

## Version

## Lifecycle

## Effective Period

## Market / Tenant Scope

## Specifications

## Characteristics

## Relationships

## Rules

## Prices

## Mappings

## Ownership

## Audit

106. Rule Template

Rule ID:
Version:
Scope:
Inputs:
Condition:
Outcome:
Priority:
Explanation:
Effective period:
Owner:
Tests:

107. Impact Analysis Template

Change:
Change class:
Affected offerings:
Affected tenants:
Open drafts:
Open quotes:
Order mappings:
Downstream consumers:
Rollback:
Approval:

108. Senior Engineer Operating Model

Keep semantics strong

Avoid generic metadata.

Require publication boundaries

No direct production mutation.

Treat rules as code

Version, review, test, observe.

Protect historical transactions

Pin versions or snapshots.

Challenge over-configuration

Some behavior belongs in code.

Make impact visible

Semantic diff and blast radius.

Design operations

Cache, rollback, incident, and reconciliation.

Enable product users safely

Self-service with guardrails.

109. Internal Verification Checklist

Catalog model

• What entities exist?
• Is ProductSpecification distinct from ProductOffering?
• Are bundles and relationships explicit?
• How are characteristics typed?

Runtime

• Is catalog interpreted dynamically or compiled?
• What engine/version executes it?
• How is cache keyed?
• How is explainability provided?

Lifecycle

• Are drafts mutable?
• Are publications immutable?
• How are effective dates handled?
• Can publications be rolled back?

Governance

• Who authors?
• Who reviews?
• Who publishes?
• Who activates?
• Is separation of duties enforced?

Testing

• Are golden scenarios maintained?
• Are rule conflicts detected?
• Are pricing and order transformations tested?
• Is publication tested as a whole?

Compatibility

• What happens to open sessions?
• What happens to draft quotes?
• Are accepted quotes pinned?
• Can retired offerings be modified?

Operations

• What metrics exist?
• How is catalog incident handled?
• How are cache/index/artifact states reconciled?
• Is pilot rollout available?

110. Practical Exercises

Exercise 1 — Catalog-driven spectrum

Classify current architecture from display-only to executable catalog.

Exercise 2 — Behavior inventory

List which behaviors are catalog-driven, code-driven, or external.

Exercise 3 — Publication pipeline

Design validation, test, activation, and rollback.

Exercise 4 — Golden scenarios

Create ten representative product/configuration/pricing cases.

Exercise 5 — Semantic diff

Define what a meaningful catalog change report should show.

Exercise 6 — Over-configuration audit

Identify metadata that would be safer as code or explicit service logic.

111. Part Completion Checklist

You are done if you can:

• explain catalog-driven architecture;
• distinguish catalog data from executable behavior;
• model draft, publication, and activation;
• version catalog coherently;
• design semantic validation;
• protect open and historical transactions;
• test configuration, pricing, and transformation;
• manage cache and runtime artifacts;
• govern authorship and activation;
• and identify over-configuration risks.

112. Key Takeaways

1. Catalog can be an executable commercial model.
2. Metadata interpreters are production code.
3. Published catalog should be reproducible.
4. Schema validation is not enough.
5. Rules need semantic analysis and scenario tests.
6. Open and accepted transactions require compatibility policy.
7. Runtime version and publication must be visible.
8. Catalog agility needs governance and rollback.
9. Not every behavior should become configuration.
10. Internal CSG catalog behavior must be verified.

113. References

Conceptual baseline:

• General product-catalog, metadata-driven, and catalog-driven architecture practices.
• Domain-Driven Design, schema governance, and rule-engine concepts.
• Continuous delivery, immutable artifacts, semantic versioning, and progressive rollout.
• TM Forum Product Catalog and Product Offering domain vocabulary.

These references do not define internal CSG catalog implementation.