Domain-Driven Design breakdown of the Adidas brand compliance scope using CHILI Publish and Media Magic, focusing on core scenarios involving brand compliance and creative automation. Includes the 4+1 architectural views (Logical, Process, Development, Physical, and Scenarios) with PlantUML diagrams, specifically tailored for a Python backend (hosted on Azure) with a Blazor WebAssembly frontend. Includes integration samples (pseudo) with CHILI Publish’s APIs wherever relevant to orchestrate workflows and process flows.
Adidas Brand Compliance Automation – DDD & 4+1 Architecture
Introduction
Adidas’ marketing teams produce a high volume of campaign assets (e.g. images, PDFs, videos) that must adhere to strict brand guidelines. This architecture addresses brand compliance automation for Adidas’ assets by integrating CHILI Publish (for template-based creative automation) and MediaMagic (for AI-driven compliance checking). The goal is to replace manual quality control with an intelligent workflow, increasing efficiency, accuracy, and scalability in compliance checks (Adidas Brand Compliance Scope.docx). MediaMagic will check each asset against Adidas’ global brand guidelines and the specific Z.N.E. campaign toolkit (Adidas Brand Compliance Scope.docx), while CHILI Publish will generate on-brand creative variants quickly via Smart Templates. A kanban-style board interface (Blazor WASM front-end) will visualize the flow of each asset from creation to approval, enabling users to track progress and intervene if issues arise.
Domain-Driven Design Breakdown
Bounded Contexts and Domain Model
-
Creative Automation Context (CHILI Publish integration):
Purpose: Manage template-based creation of marketing assets using CHILI Publish’s engine.
Entities: Template (a CHILI Smart Template defining a design with variable elements and rules), GeneratedAsset (an artwork instance produced from a template, e.g. a PDF or image).
Value Objects: TemplateID, AssetSpecification (e.g. format, dimensions).
Domain Services: TemplateRenderingService – calls CHILI’s API to render a Template into a final asset; ChiliIntegrationService – encapsulates REST calls for template listing, document creation, and editor embedding. -
Brand Compliance Context (MediaMagic rules engine):
Purpose: Enforce Adidas brand guidelines by automatically checking assets against defined rules.
Entities: Guideline (a collection of rules for a brand or campaign), ComplianceRule (an individual rule – e.g. “Logo must be at least 10mm and placed in upper-left”), ComplianceReport (the result of checking one asset, including pass/fail status and issues), Issue (a violation detected on an asset).
Value Objects: RuleID, IssueDetail (descriptive info for an issue, e.g. expected vs actual logo size).
Domain Services: ComplianceCheckerService – uses MediaMagic’s AI/multi-agent system to verify an asset (e.g. image or PDF) against the rules and produce a ComplianceReport; RulesEngine (internal to MediaMagic, encapsulated by ComplianceChecker) – evaluates rules like logo placement, font usage, etc (Adidas Brand Compliance Scope.docx). -
Workflow Orchestration Context (Kanban flow & coordination):
Purpose: Coordinate end-to-end asset creation and compliance validation, presenting it as a flow (Kanban board).
Entities: Campaign (e.g. Adidas Z.N.E. Autumn/Winter '24 campaign – grouping assets and associated guidelines (Adidas Brand Compliance Scope.docx)), Asset (a marketing asset file to be created or checked; can be an image, PDF, etc. (Adidas Brand Compliance Scope.docx)), WorkflowStage (a stage in the process, such as Design, Pending Compliance, Approved, Needs Fix).
Value Objects: AssetStatus (an enumeration of states an Asset can be in, corresponding to board columns), CampaignID.
Domain Services: WorkflowService – orchestrates the transitions (e.g. when an asset is created, trigger compliance check, then advance its status); NotificationService – publishes events or updates to the UI (e.g. via SignalR or polling) when an asset’s status changes.
Entities and Aggregates
In this domain, aggregates ensure consistency of complex operations. For example, Campaign can be an aggregate root that encompasses its Guidelines and Assets. An Asset entity (within a Campaign) holds references to its source (either a Template or an uploaded file) and the latest ComplianceReport. Assets are uniquely identified (AssetID) and treated as the primary unit of workflow. The ComplianceReport and its Issues can be treated as value objects attached to an Asset (they don’t exist independently of an Asset). The Template entity is part of the Creative Automation context and is managed separately by CHILI (it might be referenced by Asset as an external reference or ID when an asset is generated from a template).
Value objects like AssetStatus or IssueDetail convey descriptive aspects with no independent lifecycle. For instance, AssetStatus (e.g. PENDING_CHECK, COMPLIANT, NON_COMPLIANT) is a value that changes over time but is always tied to an Asset. IssueDetail contains data like the rule violated and a message, but is only meaningful as part of a ComplianceReport.
Domain services are used where complex logic spans entities or contexts. The ComplianceCheckerService is a domain service in the Compliance context; it doesn’t own data itself but encapsulates the process of running all rules checks (potentially by delegating to multiple specialized agents) and compiling results into an Issues list. Similarly, TemplateRenderingService in the Creative context takes a Template plus user input data and produces a new Asset – internally using CHILI’s APIs but exposing a simple method to the domain (e.g. generateAsset(campaign, template, data)). The WorkflowService in Orchestration context coordinates calls between these services: e.g., upon a user’s request it might call generateAsset(...) then pass the result into checkCompliance(...), updating the Asset aggregate accordingly through each step.
Core User and System Scenarios
Scenario 1: Compliance Check on Existing Asset (Manual Content)
- Asset Submission: A user (e.g. a brand manager) or an automated job submits an existing campaign asset (for example, a finished poster PDF or banner image) for compliance checking (Adidas Brand Compliance Scope.docx). The asset is registered in the system as an Asset entity under a specific Campaign, with status set to “Pending Compliance”.
- Rule Evaluation: The ComplianceCheckerService (MediaMagic) analyzes the asset against the Adidas global guidelines and the campaign-specific rules (Adidas Brand Compliance Scope.docx). It checks for all defined rules (logo placement, font correctness, etc. (Adidas Brand Compliance Scope.docx)). Under the hood, MediaMagic might use multiple AI agents in parallel (computer vision for detecting logo size/position, OCR for text and font detection, etc.) to speed up analysis.
- Report Generation: MediaMagic returns a result, which the service wraps into a ComplianceReport domain object. This report includes an overall status (e.g. FAILED if any rule was violated) and a list of Issues for each rule broken (e.g. “Logo too small (8mm) – minimum is 10mm” or “Unauthorized font used in tagline”).
- User Feedback: The Asset’s status is updated in the system (e.g. to Non-Compliant if issues were found, or Compliant if it passed all checks). The WorkflowService notifies the front-end to update the board. The user sees the asset card move to either an “Issues Found” column or “Approved” column. They can click to view the ComplianceReport details (issues listed) on the UI.
- Iteration: If issues exist, the user may choose to correct them. For a manually created asset, this means going back to a design tool to fix the problems (or using CHILI’s editor if the asset has an associated template). The corrected asset can then be resubmitted, creating a new ComplianceReport. This cycle continues until the asset is Approved/Compliant. If no issues are found, the asset is immediately marked approved and ready for use.
Scenario 2: Template-Based Asset Creation and Compliance (Automated Content)
- Template Selection & Input: A user starts a new asset creation using a CHILI Publish Template. For example, they select the Z.N.E. Campaign Social Post Template. The user provides custom content for the template’s variables (e.g. text headlines, product images, regional language selection) via the Blazor UI form.
- Automated Artwork Generation: The TemplateRenderingService in the backend takes the template ID and the user’s input data, and calls the CHILI API to generate the document. CHILI’s engine produces a branded asset (e.g. a high-resolution PDF or PNG) based on the Smart Template. This output is now stored/registered as an Asset in the system (with a reference to its Template origin and assigned a new AssetID). The asset’s initial status might be “Generated/Pending Compliance”.
- Auto Compliance Trigger: As soon as the asset is created, the WorkflowService invokes the ComplianceCheckerService to run a compliance check (this can be done synchronously in the user’s flow, or asynchronously via a job queue if generation is time-consuming). The MediaMagic engine analyzes the newly created asset against all rules (the same as in Scenario 1). Because the asset was generated from a controlled template, ideally it should have fewer issues; however, content variations (like different text lengths or localized content) might introduce rule violations (e.g. text overflow that breaks the layout grid).
- Results & Workflow Update: Once the ComplianceReport is received, the backend updates the Asset’s status. If the report is clean (no issues), the asset can be marked Compliant and move directly to an “Approved” stage. If there are issues, the asset is moved to a “Needs Fix” stage on the board. In this scenario, “fix” might involve adjusting the template input (e.g. shorten a text string that was too long) or tweaking the template design itself if a systematic issue is found.
- User Notification: The front-end board reflects the outcome: the new asset card might display a green check (compliant) or a red alert icon (indicating issues). The user can click the card to see a preview of the generated asset (since CHILI can provide a preview/URL) and review any issues flagged. Since CHILI templates have predefined rules (e.g., max text lengths, safe zones for images), many compliance issues are prevented at the source. Any remaining issues can often be fixed by minor content adjustments and re-running the generation.
- Approval: After any necessary iterations (modify input or template, re-generate, re-check), the asset eventually passes all compliance checks. The board now shows it in “Approved” and it can be delivered or published. The system can optionally compare the compliance results of manual vs. CHILI-generated assets to quantify improvements (as noted in the POC, comparing error rates between manual and automated assets is an objective (Adidas Brand Compliance Scope.docx) (Adidas Brand Compliance Scope.docx)).
Architecture Views (4+1 Model)
Logical View
The Logical View focuses on the high-level structure of the solution in terms of domains, entities, and their interactions. It reflects the DDD breakdown of contexts and how they relate. Key logical components include the Asset (central to workflow), the Campaign that provides context (and rules via Guidelines), the Template for generation, and the integration points for compliance checking. The diagram below illustrates the main domain classes and relationships:
Web server is returning an unknown error Error code 520
What happened?
There is an unknown connection issue between Cloudflare and the origin web server. As a result, the web page can not be displayed.
What can I do?
If you are a visitor of this website:
Please try again in a few minutes.
If you are the owner of this website:
There is an issue between Cloudflare's cache and your origin web server. Cloudflare monitors for these errors and automatically investigates the cause. To help support the investigation, you can pull the corresponding error log from your web server and submit it our support team. Please include the Ray ID (which is at the bottom of this error page). Additional troubleshooting resources.
Web server is returning an unknown error Error code 520
What happened?
There is an unknown connection issue between Cloudflare and the origin web server. As a result, the web page can not be displayed.
What can I do?
If you are a visitor of this website:
Please try again in a few minutes.
If you are the owner of this website:
There is an issue between Cloudflare's cache and your origin web server. Cloudflare monitors for these errors and automatically investigates the cause. To help support the investigation, you can pull the corresponding error log from your web server and submit it our support team. Please include the Ray ID (which is at the bottom of this error page). Additional troubleshooting resources.
Figure: Logical view of the domain model, showing key entities (Campaign, Asset, Guideline, Template, etc.) and their relationships. Bounded contexts are indicated by packages. Note that an Asset may be linked to a Template if it was auto-generated, but the Template lives in a separate context (hence a dotted line).
In this model, Campaign is associated with a set of ComplianceRules (through a Guideline aggregate) which apply to all its Assets. Asset is the central entity that gets created (via Template or upload) and checked. The ComplianceReport is linked to an Asset after a check. The Template and GeneratedAsset classes reside in the Creative context; often the actual Template definitions and rendering are handled by CHILI externally, but we represent them logically to understand the link between created assets and their templates.
Development View
The Development View (implementation view) describes the system’s decomposition into modules, components, and layers. This system is built with a Python backend and a Blazor WebAssembly frontend, alongside external services (CHILI and MediaMagic). The backend follows a layered approach: the domain logic (contexts) is implemented in Python (for example, using FastAPI or Flask to expose REST endpoints), and integration with external APIs is handled in the infrastructure layer. The Blazor WASM frontend (running in the user’s browser) communicates with the backend via HTTP calls to perform actions and retrieve data.
Below is a component/deployment diagram for the major components and their interactions:
Figure: Development view showing the main software components. The Blazor WASM client runs in the user’s browser, communicating with the Python API backend hosted on Azure. The backend in turn integrates with the CHILI Publish API (for creative generation) and the MediaMagic engine (for compliance checks). A database or storage component persists assets, templates metadata, and compliance reports.
Component responsibilities: The Blazor WASM frontend is responsible for the user interface – it presents the Kanban board, forms for asset creation (template input or file upload), and views of reports. It’s purely client-side .NET code (C# running in the browser via WebAssembly), obtaining data from the backend via API calls. The Python API Backend contains sub-components or modules corresponding to the bounded contexts: e.g., a ComplianceModule (with endpoints like /compliance/check), a TemplateModule (with endpoints like /generate), and a WorkflowModule (for endpoints that list campaigns, assets, move stages, etc.). These modules encapsulate the domain logic and use domain services. The backend also includes integration adapters: e.g., a ChiliClient class to call CHILI REST endpoints and a MediaMagicClient to call the compliance engine.
The MediaMagic Compliance Engine is an external service (which could be deployed as part of our solution or provided by a vendor) that receives asset data and returns compliance analysis. The CHILI Publish API Service is provided by CHILI (either a cloud SaaS or a hosted server) and provides endpoints for document/template operations. Both are treated as external components the backend interacts with. The Database/Storage component (for instance, Azure Blob Storage and/or an Azure SQL/NoSQL database) stores persistent data: campaign info, references to asset files (possibly the files themselves if not kept in CHILI), templates (if any stored locally or their IDs), and compliance reports for audit/history.
Code organization: In a DDD-inspired implementation, each bounded context can be a separate Python module or even a separate microservice. For example, we might have a package compliance/ containing the Compliance context’s entities (ComplianceRule, ComplianceReport, etc.), repository classes for storing reports, and a service class for running checks (wrapping MediaMagic calls). Similarly, a creative/ package for Template and generation, and a workflow/ package for Campaign, Asset and orchestration logic. The Python backend could be a monolith logically partitioned this way, or these contexts could be split into distinct deployable services that communicate via internal APIs or messaging. Given the Azure deployment, one could implement the compliance checking as an Azure Function (triggered when a new asset is available) to offload heavy AI processing, but for simplicity, the POC might keep it synchronous in the main API process. The front-end Blazor app is a separate project, which gets deployed as static files (HTML/JS/WASM) and served to users, interacting with the backend’s REST interface.
Process View
The Process View focuses on the dynamic behavior of the system at runtime, particularly how multiple processes or threads execute and interact. In this architecture, the key processes include the front-end user interactions, the backend processing flows, and importantly the MediaMagic internal concurrent checks (multi-agent analysis). The system makes use of parallelism to speed up compliance checking: MediaMagic’s engine can run multiple rule checks at once on the asset. Likewise, the workflow might involve asynchronous processing (the user doesn’t have to wait idle for long operations; they can be notified when done).
Below is a sequence diagram highlighting the runtime process for an asset going through creation and compliance, emphasizing parallel rule checking:
Figure: Process view sequence diagram for the end-to-end workflow of creating an asset and running compliance. The MediaMagic engine internally performs parallel checks through multiple specialized agents (logo, font, text), which run concurrently to reduce total processing time. The Workflow Orchestrator (part of the backend) coordinates the calls to CHILI and MediaMagic, and updates the UI.
In the sequence above, after the user initiates an asset creation, the backend orchestrator calls CHILI (synchronous step shown). Once the asset is generated, the compliance check is submitted. The par section indicates concurrent operations: the MediaMagic Orchestrator spawns or coordinates multiple checking agents in parallel (this could be threads or separate microservices in the MediaMagic implementation). For example, one agent uses computer vision to check if the Adidas logo in the asset is in the correct position and above the minimum size; another agent scans text elements (via OCR or reading metadata from PDF) to ensure only approved fonts are used and the tone of voice or content matches guidelines; another might check that text complies with language or legal requirements (e.g. correct trademark symbols, no banned phrases). These agents run independently and then return their findings, which MediaMagic aggregates into a single ComplianceReport. The backend then receives that and updates the domain model (Asset status and Issues).
From a concurrency perspective, the system may implement the compliance check as an asynchronous job: the backend might not block the API call until completion; instead, it could quickly return a confirmation to the UI that the asset is “in progress” and later push results. However, for the POC simplicity, it might appear synchronous to the user (with a loading indicator until results arrive). The design supports scalability: for many assets, multiple MediaMagic instances or agents could run in parallel, and Azure could scale out the backend if needed.
Physical View
The Physical View describes how the system is deployed on hardware or cloud infrastructure. For this solution, the deployment targets Microsoft Azure for hosting the backend and leveraging cloud services, and uses the client’s browser for the Blazor app. The diagram below outlines the deployment architecture:
Web server is returning an unknown error Error code 520
What happened?
There is an unknown connection issue between Cloudflare and the origin web server. As a result, the web page can not be displayed.
What can I do?
If you are a visitor of this website:
Please try again in a few minutes.
If you are the owner of this website:
There is an issue between Cloudflare's cache and your origin web server. Cloudflare monitors for these errors and automatically investigates the cause. To help support the investigation, you can pull the corresponding error log from your web server and submit it our support team. Please include the Ray ID (which is at the bottom of this error page). Additional troubleshooting resources.
Figure: Physical view of deployment. The Blazor WebAssembly app is loaded in the user’s web browser. The Python backend (FastAPI) is hosted on Azure App Service (or as Azure Functions/container), providing REST endpoints. MediaMagic’s engine is deployed as a service (which could be containerized on Azure Kubernetes, or an Azure Function for AI processing). CHILI Publish is provided as a cloud service (CHILI GraFx SaaS or a dedicated instance). Azure Storage and/or database hold assets and data. Network connections (Internet/Azure backbone) connect these components securely.
Deployment details: End-users access the Blazor app via a URL; the static content (WASM files, HTML, JS) can be served from Azure Blob Storage or directly from the App Service. The Blazor app then communicates with the Backend API over HTTPS (Azure could use a Front Door or API Management as needed for routing, omitted for simplicity). The Backend API runs on Azure – this could be an App Service Web App hosting a container or a direct deployment of the Python app. It might also be broken into multiple services (e.g., a dedicated compliance microservice) as the system grows.
The MediaMagic AI Service could be an Azure Container Instance or a set of Azure Functions utilizing cognitive services. It needs capabilities like image analysis (for logos), text analysis (for fonts/text) – possibly powered by Azure Cognitive Services (Custom Vision, OCR, etc.) behind the scenes. For the POC, it might be a single VM or container running the MediaMagic engine. Communication with MediaMagic happens via REST API calls (the backend sends the asset or a reference to it, along with which rules to apply). This service likely resides in the same Azure region or virtual network for performance.
The CHILI Publish Cloud is external; if using CHILI’s SaaS (GraFx Publisher), the backend communicates with CHILI’s endpoints over the internet. If a self-hosted CHILI Server is used, it could be an Azure VM or App Service as well. In either case, the integration is via REST calls (and possibly websocket for the editor if live editing sessions are used). CHILI outputs (generated PDFs/images) might be returned directly in the response or made available via a URL that the backend can then fetch. Large assets might be stored in Azure Storage – for example, the backend could instruct CHILI to put the output file into an Azure Blob Storage container, which MediaMagic can then access. The Azure Storage/Database is used for persisting data: metadata about campaigns, assets (with fields like status, references to blob URIs or CHILI document IDs), compliance reports (could be stored as JSON or relational data for analysis), and user information or audit logs.
Security considerations in the physical deployment include ensuring that the CHILI API keys and MediaMagic endpoints are protected (e.g., stored in Azure Key Vault, and calls happen server-to-server). The Blazor app would use authentication (Azure AD B2C or similar) to ensure only authorized Adidas/partner users access the system, and the backend verifies tokens on each call.
Scenarios (Use Case View)
The Scenarios View validates the architecture by walking through key use cases. Below are two sequence diagrams corresponding to the scenarios described earlier, to illustrate how the components interact to fulfill the requirements:
Use Case: Compliance Check for Existing Asset (Manual upload)
Figure: Scenario 1 – A user uploads an existing asset for compliance. The backend sends the asset to MediaMagic, which runs all checks and returns a report. The UI then displays the compliance status and any issues to the user.
In this use case, the Brand Designer uses the web UI to upload, say, a PDF. The front-end calls the backend (e.g., /assets endpoint to create the asset, then /assets/{id}/check). The backend obtains the asset (it could pass a direct file stream or a storage link to MediaMagic) and tells MediaMagic which ruleset to apply (here the ruleset would correspond to Adidas’s guidelines). MediaMagic processes the file and replies with a result object. The backend translates that to domain terms (Issues, etc.) and sends a simplified result to the front-end. The user sees a list of any violations (for instance, “Font X is not an approved typeface”). In a refined UI, the user might also see visual markers on a preview of the asset indicating where the issue is (if coordinates are provided by MediaMagic’s analysis, the system can overlay highlights – an enhancement beyond the core flow).
Use Case: Automated Asset Creation and Compliance (Template-driven)
Figure: Scenario 2 – A marketing user generates a new asset from a template. The system calls CHILI to produce the asset, then automatically sends it to MediaMagic for compliance checking, and finally the UI shows the result (which could be instant approval or some issues to fix).
Here the Marketing User (who may not be a designer) leverages a predefined CHILI template. The Blazor UI presents a form (fields corresponding to template variables like headline text, product image upload, etc.). When submitted, the backend calls CHILI’s API (the endpoint could be something like /documents or a specific generate endpoint) with the template ID and variable data. CHILI returns the output – in some setups, it might return a URL to download the PDF, or the PDF content itself. The backend then immediately triggers the compliance check by calling MediaMagic with that asset. This could happen in sequence as shown, or the backend could respond to the UI with a preliminary “asset created, checking compliance” message and complete the check in the background. In either case, once done, the UI gets the final status. The user might see the new asset appear on the board first as “Generating…”, then “Checking…”, and finally either “Compliant” or “Needs Changes”. The board card could also show a thumbnail of the generated asset (CHILI can provide a preview image). If issues are found, the user can click to see details and perhaps open the CHILI editor (embedded) to adjust the design or content to fix the issues, then regenerate and re-check.
These scenarios confirm that our design supports both inputs into the system: external assets and auto-generated assets. They also show how external services are orchestrated seamlessly to produce an outcome for the end user (a compliance decision), with the complexity of template rendering and AI analysis hidden behind simple API interactions.
Integration Details: CHILI Publish & MediaMagic
A crucial aspect of this architecture is how the Python backend integrates with CHILI Publish and MediaMagic to implement the domain services. Below we detail these integrations:
- CHILI Publish Integration: CHILI Publish is a creative automation platform that provides a rich API for creating and editing documents. The integration uses CHILI’s REST API (part of CHILI GraFx) to perform tasks such as retrieving templates, populating them with data, and generating output files. Every aspect of CHILI’s Smart Templates can be controlled via API (What is Chili Publish and How it Works in Sitecore Content Hub). For authentication, the system uses an API key or OAuth token provided by CHILI. To generate an asset, the backend might call an endpoint like
/documentsor/templates/{id}/generatewith a JSON payload of variable values. For example:
python
# Pseudocode: Generate an asset via CHILI API
api_url = f"https://api.chili-publish.com/v1/templates/{template_id}/generate"
headers = {"Authorization": f"Bearer {CHILI_API_KEY}"}
payload = {
"variables": {
"Headline": "New Arrival: ZX Sneakers",
"ProductImage": "https://assets.example.com/images/zx.png",
"Locale": "en-UK"
},
"output": {"format": "PDF", "dpi": 300}
}
response = requests.post(api_url, json=payload, headers=headers)
result = response.json()
pdf_url = result.get("outputUrl")
In this snippet, we send variables (text, image URLs, etc.) to CHILI along with output settings. CHILI processes the Smart Template and returns a URL to the generated PDF. The Smart Template ensures that the design remains within predefined rules (e.g., text fits in designated areas, only brand fonts/colors are used). This concept of predefined rules in templates means a lot of brand compliance is enforced at creation time (What is Chili Publish and How it Works in Sitecore Content Hub) – users can only adapt designs within constraints, ensuring brand consistency. CHILI also supports generating multiple output formats (like different sizes or localizations) from the same template, further automating creative production.
Embedding CHILI Editor: In cases where a user needs to fine-tune the design, the CHILI Editor web component can be embedded into the workflow. For instance, the Blazor app could open an iframe or new window pointing to CHILI’s online editor for the generated document. CHILI’s API can generate a secure session/editor URL for a given document which the frontend can load. This allows manual edits while still respecting the template’s locked rules (for example, a user could tweak the position of an image within an allowed range). After editing, the document can be saved via CHILI and then re-checked by MediaMagic. This integration of CHILI into the workflow enables an ongoing approval workflow where users iterate on the asset within CHILI until it passes compliance (Adidas Brand Compliance Scope.docx).
- MediaMagic Rules Engine: MediaMagic is an AI-powered compliance engine by Northell that uses computer vision and other AI techniques to inspect media content. Integration with MediaMagic typically involves sending the asset (or a link to it) and specifying which rules or profile to apply. The MediaMagic API might have an endpoint like
/compliance-checkwhere we POST the asset data. For example:
python
# Pseudocode: Submit asset to MediaMagic for compliance checking
mm_url = "https://api.mediamagic.ai/v1/compliance-check"
payload = {
"assetUrl": pdf_url, # or could send file bytes in a real scenario
"ruleset": "Adidas_ZNE_AW24" # identifier for the relevant guidelines
}
report = requests.post(mm_url, json=payload, headers={"Authorization": f"Bearer {MM_API_KEY}"}).json()
issues = report.get("issues", [])
status = report.get("status") # e.g., "PASSED" or "FAILED"
MediaMagic’s internal implementation will analyze the asset at a component level (each element in the design) and possibly frame-by-frame for video content (MediaMagic – northell.). It ensures compliance by checking everything the asset “should or shouldn’t contain” (MediaMagic – northell.) (MediaMagic – northell.). The multi-agent architecture means it might run several analyses in parallel: e.g., a logo detector (to find the Adidas logo and measure it), a text detector (OCR to extract all text and compare fonts or banned words), a layout analyzer (to verify alignment with grid and safe zones). The response (issues) would list each problem found, typically with a reference to the rule violated (which our domain model maps to a ComplianceRule). For instance, an issue might look like: {"rule":"LogoSizeRule", "message":"Logo is 8mm but minimum is 10mm", "severity":"ERROR"}.
The ComplianceCheckerService in our backend takes this response and transforms it into our ComplianceReport domain object. It might also log the results or attach images/thumbnails for reporting. If MediaMagic provides annotated images (e.g., an image with regions circled where issues are), the system could store them in Azure Storage for the UI to display. MediaMagic’s ability to highlight potential issues automatically means the user does not have to manually scrutinize each asset (MediaMagic – northell.) – the system brings the attention directly to what’s wrong.
- Workflow Orchestration & Data Flow: The integration of CHILI and MediaMagic is orchestrated by the backend’s WorkflowService (or orchestrator logic). This service manages state and ensures the two systems work in tandem. For example, when a user triggers a template-based creation:
- Generate Asset: Call CHILI (as above). If CHILI fails (e.g., template ID not found or variable data out of bounds), catch the error and report back to the user (perhaps as a validation error). If it succeeds, get the asset URL or file.
- Store/Reference Asset: Save the asset file or its URL in our system. Often, the asset might be stored in CHILI’s repository or returned as a file. In a cloud workflow, we might store the file in Azure Blob Storage and just keep the URI. The Asset entity is created in the database with status “Pending Compliance”.
- Trigger Compliance: Call MediaMagic with the asset reference. This could be done synchronously or by enqueuing a message to a queue that a compliance worker listens to (for scalability). For the POC, a direct call is made and the process waits for the result.
- Handle Result: When MediaMagic returns the ComplianceReport, update the Asset’s status and save the report (issues list). If the call times out or fails, mark the Asset with an error status so the user knows to retry.
- Update Frontend: The server either pushes a notification (if using WebSockets/SignalR) or the frontend polls for status. In our scenario, because it’s a board UI, the client might periodically refresh asset statuses or use an event stream. The end result is the card on the board moves to the correct column and shows any pertinent info.
Throughout this flow, domain events could be used internally to decouple steps. For instance, the Asset entity could emit an event “AssetCreated” which triggers a handler to start compliance checking. This is a DDD pattern that helps keep the creation logic and checking logic separate. Another event “ComplianceChecked” could carry the outcome, which a handler uses to update status and perhaps trigger a notification event for the UI. In a simpler implementation, the WorkflowService could just call methods sequentially (as in a script), but the event-driven approach would facilitate future scaling (e.g., handling many assets concurrently).
Error Handling & Edge Cases: Integration design also covers things like what if CHILI or MediaMagic are unavailable or return an error. The system should handle CHILI API errors (e.g., malformed template data) by informing the user to correct input. If MediaMagic finds too many issues or an unexpected condition (say it cannot parse the file), the system might mark the asset as “Compliance Error” requiring manual review. These states can also appear on the board (maybe a special color for system errors vs. rule violations).
Additionally, while not in the immediate scope, the architecture can incorporate feedback loops: for example, if the same type of issue is consistently found by MediaMagic in CHILI-generated assets, that might indicate the template itself needs updating (which would be a task for the design team). The domain design allows capturing such insights via the stored ComplianceReports.
Conclusion
This Domain-Driven Design and 4+1 architectural breakdown demonstrates how Adidas’ brand compliance workflow can be transformed through intelligent automation. By clearly separating the Creative Automation domain (CHILI Publish templates) and the Brand Compliance domain (MediaMagic rules engine), and orchestrating them via a dedicated workflow layer, the system achieves a flexible yet robust design. Key benefits of this architecture include:
-
Automation of Compliance Checks: The tedious process of manual QA is minimized. MediaMagic’s AI-driven, component-level analysis ensures that each asset is thoroughly inspected for branding issues, and it does so faster and more consistently than a human could. Its cognitive backbone can analyze assets frame-by-frame (even for videos) and flag issues in real-time (MediaMagic – northell.) (MediaMagic – northell.). The multi-agent parallelism means even complex checks (logo, text, layout, etc.) happen within the same workflow step, providing quick feedback to users.
-
Creative Efficiency and Consistency: CHILI Publish empowers marketing teams to create variants of content quickly through Smart Templates. These templates enforce brand style guides at the creation stage (e.g., locked corporate fonts, predefined color swatches, safe text areas), effectively reducing the chance of errors (What is Chili Publish and How it Works in Sitecore Content Hub). This not only speeds up content production but also means that the generated output is born compliant to a large extent. The integration also allows non-designers to produce on-brand materials (as noted, templates let users generate high-quality content without graphic design skills (What is Chili Publish and How it Works in Sitecore Content Hub)), freeing up designers for more complex tasks.
-
Unified Flow with Visibility: Using a Kanban-style board (a core part of the Workflow context) provides stakeholders with end-to-end visibility. Each asset card carries metadata (status, origin, etc.) and can move through stages automatically. This transparency helps in coordinating between teams – for example, if an asset is stuck in “Needs Fix”, a designer can be alerted to intervene. The board metaphor aligns with agile marketing workflows and makes the process intuitive.
-
Scalability & Maintainability: The architecture is designed to scale. Each bounded context could be developed and scaled independently – for instance, if compliance checking demands increase, the MediaMagic service can scale out (more agent instances or stronger VMs) without affecting the template rendering service. The use of Azure cloud ensures we can handle spikes (like a large batch of assets before a product launch) by leveraging cloud autoscaling. Maintainability is enhanced by the clear separation of concerns: if Adidas updates its brand guidelines, we update the rules in the Compliance context; if we adopt a new creative format, we add new templates in CHILI. The Python backend acts as a cohesive integration point but keeps the logic of each domain modular.
-
Extensibility: The design is future-proof for extensions. For example, support for video adaptations (dynamic video compliance) can be added by extending MediaMagic’s capabilities and adding new ComplianceRules for motion or duration checks (Adidas Brand Compliance Scope.docx). The domain model can accommodate new types of Assets (e.g., a video asset with multiple frames to check) and corresponding rules. The workflow can also integrate a live dashboard for brand and retail partners to monitor compliance in real-time (Adidas Brand Compliance Scope.docx) – since all data (assets, issues) are stored, a reporting module could aggregate this info and present KPIs (like % of compliant assets per campaign). Moreover, integration with enterprise DAM systems is facilitated by the API-first approach – e.g., assets could be pulled from or pushed to a central DAM after approval, without changing core logic (just another adapter in the workflow).
In summary, this architecture leverages the strengths of CHILI Publish (template-driven creative automation) and MediaMagic (AI compliance checks) to deliver a Media Compliance Board for Adidas. It provides a blueprint for how technology can enforce brand standards at scale, ensuring that every Adidas campaign asset, from print to digital, is on-brand and error-free with significantly less manual effort. The result is a more efficient, reliable, and intelligent brand compliance workflow, turning a once labor-intensive process into a streamlined digital solution. (Adidas Brand Compliance Scope.docx) (Adidas Brand Compliance Scope.docx)