Governance-Aware Modeling

By Optimizely Education
Published: Mar 9, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Tree control: Use [AvailableContentTypes] to stop pages from wandering into places they should never have been allowed to discover.
Area safety: Constrain ContentArea properties with marker-interface-based [AllowedTypes] to prevent layout mismatches.
Data integrity: Use IValidate<T> for business rules that simple attributes cannot enforce.
Scalability payoff: Governance-aware modeling keeps content cleaner, Graph queries saner, and editors less likely to turn the tree into modern art.

In an enterprise Optimizely CMS 13 deployment, the editorial experience is just as critical as the end-user experience. As a solution scales to dozens of developers and hundreds of editors, the risk of editorial chaos, where content is created in incorrect locations, components are mismatched, and the site tree becomes an unnavigable labyrinth, increases exponentially. This chaos does not just hurt editor productivity. It also degrades the performance of downstream consumers like Optimizely Graph.

The Technical Definition of Governance

Governance-aware modeling is the high-level application of the CMS type system to bake structural rules directly into the C# codebase. This ensures that the system enforces architectural decisions automatically, removes the burden of manual documentation from editors, and helps keep the data API-first ready.

By defining these rules in code, you transform the CMS from a passive content bucket into a proactive structural engine that guides editors toward success while preventing technical debt.

1. The Hierarchy Gatekeeper: [AvailableContentTypes]

The site tree should never be an open field where any page can exist anywhere. Every node in your hierarchy should have a specific functional purpose. The [AvailableContentTypes] attribute is the primary tool for structural governance, allowing developers to define precisely what can be created where.

1.1 Parameters of Control

Include: Explicitly lists the classes that are allowed as children. This is the most common use case for hubs and categorical containers.
Exclude: Lists specific types that are strictly forbidden. This takes priority over global settings and is useful for ensuring that legacy types are not used in fresh campaign branches.
IncludeOn: Defined on a child type to say, “I am only valid if created under these specific parents.” This inverse rule is highly effective for landing pages or campaign types that should only exist under a campaigns folder.

1.2 Technical Scenario: The Multi-Regional News Hub Protection

In an ungoverned system, an editor might accidentally move a product detail page into the news hub. By applying structural constraints, you keep the index logically consistent. This structural integrity is especially important for headless delivery, because it helps ensure a GraphQL query for news items does not return unrelated landing pages or teaser blocks.

[ContentType(DisplayName = "News Hub", GUID = "123-abcd-...", ...)]
[AvailableContentTypes(
    Include = new[] { typeof(NewsArticlePage) }, // Only articles allowed
    ExcludeOn = new[] { typeof(ProductLandingPage) } // Prevents nesting under Products
)]
public class NewsHubPage : BasePageData 
{ 
    /* Page properties go here... */ 
}

2. Area Security: Interface-Based [AllowedTypes]

The ContentArea is usually the epicenter of layout chaos. Without constraints, an editor might try to drag a high-bandwidth full-screen video block into a narrow footer column. That leads to broken responsive layouts, CSS conflicts, and client-side performance penalties.

2.1 Advanced Pattern: Marker Interfaces for Component Safety

Instead of listing dozens of individual block types in attributes, which becomes a maintenance headache as the component library grows, use marker interfaces. This lets you categorize blocks by visual compatibility. It is a scalable pattern that keeps property definitions clean while making the component system safer.

// 1. Define visual compatibility markers
public interface ILayoutSidebarElement { }
public interface ILayoutMainBodyElement { }

// 2. Decorate blocks based on their design intent
public class ImageTeaserBlock : BlockData, ILayoutSidebarElement { ... }
public class RawHtmlBlock : BlockData, ILayoutMainBodyElement { ... }

// 3. Constrain the property in the Page Model
[Display(Name = "Right Sidebar Items")]
[AllowedTypes(typeof(ILayoutSidebarElement))]
public virtual ContentArea SidebarItems { get; set; }

3. High-Integrity Data: Custom Server-Side Validation

Standard attributes like [Required] only cover simple presence checks. For enterprise-grade complexities, such as cross-property logic or media dimension checks, you need the IValidate<T> interface.

3.1 The Validator Pipeline Lifecycle

The CMS engine automatically discovers any class implementing IValidate<T> through the service container and registers it in the internal validation pipeline. These checks run just before the database commit occurs, creating a final safety net for data integrity before content is indexed in the cloud.

public class CampaignValidator : IValidate<CampaignPage>
{
    public IEnumerable<ValidationError> Validate(CampaignPage instance)
    {
        // Business Rule: End Dates must follow Start Dates by 24h
        if (instance.StopPublish < instance.StartPublish.AddHours(24))
        {
            yield return new ValidationError
            {
                ErrorMessage = "Campaign duration must be at least 24 hours.",
                PropertyName = nameof(instance.StopPublish),
                ValidationType = ValidationErrorType.Error 
            };
        }

        // Complex Rule: Check for mandatory assets on Global campaigns
        if (instance.IsGlobalLaunch && ContentReference.IsNullOrEmpty(instance.GlobalAssetFolder))
        {
             yield return new ValidationError { ErrorMessage = "Global campaigns require an Asset Folder." };
        }
    }
}

4. Architectural Anchors: Structural Container Types

Large CMS builds often suffer from global asset bloat, where the block assets pane contains thousands of items in a flat list. That hurts performance in the CMS search UI and leads to asset fatigue for editors.

Architectural solution: Use container pages, meaning page types with no rendering template, as physical folders within the site tree.

Settings Containers: Store global configuration blocks such as social links or site credentials in dedicated branches.
Content Pillars: Group articles and media into distinct branches to improve the performance of IContentLoader.GetChildren by keeping counts per node manageable. This also reduces locking pressure on the database when multiple editors work in the same branch.

5. Recurrence Governance: Depth-Charge Protection

In CMS 13, it is technically possible to nest blocks within blocks through property composition. Without governance, an editor could create a recursive loop, where Block A contains Block B, which contains Block A again. Failure to govern this depth can lead to StackOverflowException errors during the .NET rendering pipeline or during serialization for Optimizely Graph and the Content Delivery API. Always apply [AllowedTypes] to nested block properties to prevent cyclic dependencies.

Conclusion

Preventing editorial chaos at scale requires a proactive approach to structural enforcement that goes beyond manual documentation. By locking down the tree hierarchy with [AvailableContentTypes], securing content areas through marker-interface-based [AllowedTypes], and implementing rigorous cross-property validation via IValidate<T>, you create a platform that actively protects its own integrity. This governance-first mindset helps ensure that as your PaaS deployment grows to encompass millions of items, the data remains high-quality, queryable, and logically grouped. Success arrives when your code makes it technically difficult for an editor to break the design system and much easier for them to do the right thing by default.