Contribution Model

Compositional Design System / Contribution Model

Intro

Instead of design knowledge being locked inside one team, the compositional design system uses an open contribution model, inspired by how modern software teams collaborate.

Anyone can contribute new composition rules, component mappings, and design patterns. Contributions go through a review process to ensure they meet quality standards and integrate coherently with existing knowledge. Every rule is versioned, traceable, and authored, so design decisions have a clear history and rationale.

This is how the system grows with SAP, not as a monolith, but as shared, living design knowledge.

Contribution Process

<div> <div>Step</div> <div>Activity</div> </div> <div> <div>1. Propose</div> <div>Submit new rules or updates via a structured contribution process.</div> </div> <div> <div>2. Review</div> <div>Contributions are validated against design principles and checked for conflicts.</div> </div> <div> <div>3. Merge</div> <div>Approved rules become part of the system, available to all teams.</div> </div> <div> <div>4. Iterate</div> <div>Rules can be updated over time as design knowledge evolves.</div> </div>

How to Write Rules

Rules are the building blocks of the compositional design system. A rule encodes a piece of SAP design knowledge, when to apply a pattern, which components to use, and how to compose them.

Rule Definition

Rules are written in a JSON-based composition structure. Each rule definition has four parts: structure, purpose, interdependencies, and rules.

Structure

The JSON composition definition that tells the system what to render and how.

Purpose

A clear statement of the design problem this rule solves and when it applies. This is how the agent decides whether a rule is relevant to a given query.

Interdependencies

Which other rules this rule depends on, extends, or overrides. Rules don't exist in isolation, and the system reasons about them as a connected whole.

Rules

Usage guidance, edge cases, and anti-patterns baked directly into the rule, so design knowledge doesn't live only in documents no one reads.

Instead of relying on documentation, rules make design knowledge executable.