Part 4 of 4: Making Data Product Portfolio Patterns Executable
This article concludes a four-part miniseries on Data Product Portfolio Design Patterns. The series started with a simple question: if recurring business and operating problems produce recurring structures across data product portfolios, should we capture those structures as reusable design patterns rather than design every portfolio configuration from scratch? The first part defined the concept, the second proposed the first candidate pattern families, and the third examined the anti-patterns that become visible when portfolio structures are missing, duplicated, inconsistent or fragile. This final part explores what happens when the pattern language moves from human-readable guidance into machine-readable design knowledge.
Part 1: Why Data Product Portfolios Need Design Patterns
Introduces the portfolio as a design problem, defines Data Product Portfolio Design Patterns, and explains why the configuration of objectives, use cases, products, signals, KPIs, agents and relationships matters.
Part 2: A Pattern Language for Data Product Portfolios
Introduces the first candidate pattern families and examines how recurring portfolio structures around entities, decisions, signals, reference information, AI agents and operational monitoring relate and combine.
Part 3: The Anti-Patterns Hiding in Your Data Product Portfolio
Looks at structural problems such as unsupported use cases, duplication, semantic forks, fragile dependencies, missing outcome links and products that have lost their purpose.
Part 4: Making Data Product Portfolio Patterns Executable
Explores how patterns might become machine-readable, mapped to portfolio objects and relationships, and used for validation, design guidance, portfolio analysis and AI-assisted workflows.
— —
Lets begin part 4…
From pattern language to executable design knowledge
The first three parts treated patterns primarily as design knowledge for people. A portfolio pattern describes a recurring problem, the context in which it appears, the forces shaping the design, the expected configuration of portfolio elements and the consequences of choosing that structure. This already has value because it gives portfolio teams a shared way to discuss recurring structures instead of designing every initiative independently.
The next step changes the role of the pattern. If the expected portfolio structure is represented in a form that software understands, the pattern becomes something that portfolio tooling, validators and AI agents are able to inspect alongside the real portfolio. The research behind this series proposes two complementary representations for this reason: a human-readable narrative for context, reasoning and tradeoffs, and a machine-readable PortfolioPattern definition containing roles, cardinalities, required relationships, constraints, mappings, anti-pattern checks and evidence.
The human-readable version should remain important because portfolio design involves judgement. A Decision pattern might describe why feedback matters, when human review is appropriate and how latency competes with evidence quality. Those are difficult ideas to reduce to structural rules alone. The machine-readable version serves another purpose. It describes which elements are expected, how those elements relate and which observable conditions indicate that part of the pattern is missing or inconsistent.
Together, the two representations turn a pattern from documentation into reusable design knowledge that both people and software are able to work with.
The pattern should not become another source of portfolio truth
The first design choice is to keep the reusable pattern separate from the concrete portfolio. A pattern describes what a recurring configuration should look like, while the portfolio records what actually exists in one organization, domain or initiative.
The research proposes three layers for this separation. The Pattern Definition contains reusable intent, context, forces, roles, required relationships, consequences, anti-patterns and mappings. A Pattern Application connects a specific version of that pattern to actual portfolio objects and records exceptions or design decisions. The Portfolio Truth remains the real set of objectives, use cases, signals, product references, detailed products, agents, policies and graph relationships represented through the relevant standards and systems.
This separation prevents the pattern layer from becoming another catalog that slowly diverges from the portfolio. If a predictive maintenance initiative applies a Closed-Loop Decision Support pattern, the pattern should not contain another copy of the Asset product, downtime KPI or maintenance use case. It should bind its roles to those existing portfolio objects.
That principle also fits the current separation of concerns in the Open Data Products standards family. ODPS describes the detailed individual data product. ODPC represents reusable portfolio objects such as ProductReference, UseCase, BusinessObjective, KPI and Signal. ODPG represents relationships across those objects and related assets. ODPV provides shared terminology. The pattern layer would sit above these structures and describe how they participate in recurring configurations rather than duplicate them.
A machine-readable pattern needs more than a diagram
A portfolio pattern diagram is useful for understanding the idea, but software needs greater precision. The pattern needs to distinguish required roles from optional ones, specify how many instances of a role are expected, describe required relationships and retain enough information about context and consequences for meaningful review.
The research proposes a PortfolioPattern structure containing identity and version information alongside intent, context, problem, forces, applicability, roles, relationships, interfaces, governance, quality, consumers, AI implications, implementation options, consequences, anti-patterns, related patterns, mappings, examples and evidence.
A role might state that a Closed-Loop Decision Support pattern requires exactly one BusinessObjective, one or more UseCases, one or more supporting DataProducts, at least one outcome KPI and at least one feedback Signal. An AI Agent might be optional. The relationship rules then explain which use cases use which evidence products, which KPI measures the objective and where the feedback path returns into the decision process.
The important point is that these rules describe portfolio roles rather than prescribing technical implementation. The pattern does not need to specify whether evidence arrives through a warehouse query, an event stream, an API or a file. Those choices remain part of product and architecture design. The pattern only needs enough structure to say what role the evidence plays, how it relates to the use case and what expectations follow from that relationship.
Closed-Loop Decision Support shows what this might look like
The Closed-Loop Decision Support candidate from the earlier articles provides a useful example because the expected structure is easy to understand in both human and machine terms. The human version describes a recurring decision that uses governed evidence and needs a measurable outcome and feedback path. It records forces such as evidence freshness, explainability, privacy, decision latency, human accountability and operating cost.
The machine-readable version expresses those ideas through explicit portfolio roles and relationships. A shortened representation might look like this:
pattern:
id: closed-loop-decision-support
family: decision
status: candidate
roles:
objective:
type: BusinessObjective
cardinality: "1"
useCase:
type: UseCase
cardinality: "1..*"
evidenceProduct:
type: DataProduct
cardinality: "1..*"
outcomeKPI:
type: KPI
cardinality: "1..*"
feedbackSignal:
type: Signal
cardinality: "1..*"
agent:
type: Agent
cardinality: "0..*"
relationships:
- useCase uses evidenceProduct
- outcomeKPI measures objective
- feedbackSignal informs useCaseThe full research proposal goes further by adding governance expectations, quality requirements, AI implications, related patterns, anti-pattern checks and mappings to ODPC, ODPG and ODPS. It also marks the pattern as a candidate rather than implying that it has already reached established-pattern status.
The result is still understandable to a person, but software now has enough information to inspect a real portfolio. If a portfolio contains the objective, use cases, evidence products and KPI but lacks a feedback signal, the result becomes a partial pattern match rather than a vague judgement that the portfolio “looks incomplete.”
Pattern applications connect reusable knowledge to real portfolios
A pattern definition becomes operational only after it is applied to real portfolio objects. For predictive maintenance, the application might bind the objective role to Reduce Unplanned Downtime, the use-case role to Predict Maintenance Need, the evidence roles to Asset 360, Maintenance History and Sensor Signals, the outcome KPI to Unplanned Downtime, and the feedback role to Post-Maintenance Result.
The Pattern Application records these bindings without copying the underlying objects. It also provides a place to record accepted exceptions. Perhaps the organization has decided that the first implementation will use human recommendations only and therefore has no Agent role. Perhaps feedback arrives through a quarterly maintenance review rather than an automated signal. Those differences do not necessarily invalidate the pattern, but they should be explicit.
This matters because real portfolio design should not turn into mechanical compliance with a pattern catalog. Patterns describe reusable knowledge, not universal laws. A machine-readable application makes deviations visible while leaving room for people to decide whether those deviations are justified.
That idea is also important for governance. An exception with a recorded rationale is different from an accidental missing relationship. The first represents a conscious design decision. The second represents a gap that nobody has yet considered.
Existing standards already provide much of the underlying structure
The practical reason this idea is worth exploring now is that the underlying portfolio no longer needs to be represented only in diagrams and documents. ODPS, ODPC and ODPG already provide complementary machine-readable structures for individual products, portfolio objects and relationships.
ODPS remains the authoritative place for detailed data product information such as identity, access, quality, SLA and product strategy. ODPC provides the portfolio-level objects that patterns need to bind to, including ProductReference, UseCase, BusinessObjective, KPI and Signal. ODPG provides the relationship layer, which is especially important because pattern conformance depends on paths and dependencies rather than only on the presence of objects.
This separation also means that a pattern language does not need to become another competing data product standard. The research recommends keeping it as a separate registry that references the standards family instead of embedding full pattern semantics inside ODPS, ODPC or ODPG. That approach keeps the responsibilities clear and allows the pattern language to evolve without forcing changes into standards that already serve different purposes.
Get Dr. Jarkko Moilanen’s stories in your inbox
Join Medium for free to get updates from this writer.
Adjacent standards also provide useful building blocks. JSON Schema 2020–12 offers a basis for validating the structure of pattern files. SHACL provides graph constraint validation when portfolio representations are expressed through RDF. SKOS provides established structures for controlled vocabularies and reference-oriented patterns. CloudEvents already addresses event representation, which reduces the need for a pattern language to invent another event envelope. MCP distinguishes contextual Resources from executable Tools, which fits the separation between governed agent context and agent actions discussed in Part 2. The pattern layer therefore becomes an orchestration of established structures rather than an attempt to replace them.
Validation needs several layers because portfolio quality is not one thing
Making a pattern machine-readable does not mean one schema validator suddenly understands portfolio quality. Different questions require different types of validation.
The research proposes four layers. Syntax validation asks whether the pattern document itself follows the expected structure, for which JSON Schema is a natural fit. Standards validation checks whether referenced ODPC, ODPG and ODPS artifacts resolve and satisfy their own specifications. Graph validation asks whether required nodes, relationships, paths and cardinalities exist. Portfolio intelligence then looks at higher-level concerns such as duplication, weak reuse, orphan structures, semantic conflicts, stale lifecycle information and reliability risk.
These layers need to stay separate because they express different levels of certainty. A schema error is usually objective. A missing required graph edge might also be objective once a pattern has been selected. A duplicate-product warning is different because similarity provides evidence for review rather than proof that one product should be removed. A heavily reused product with many dependencies might indicate excellent design or dangerous concentration depending on its service levels, ownership and criticality.
Human review therefore remains part of the model. Machine-readable patterns improve the quality and consistency of the evidence presented to people. They should not hide context-sensitive portfolio decisions behind an automated pass or fail result.
Pattern conformance makes gaps specific
The anti-patterns discussed in Part 3 become more useful once they are evaluated against an expected pattern rather than against a universal checklist.
Suppose a portfolio applies Closed-Loop Decision Support. The pattern expects an objective, use case, evidence products, outcome KPI and feedback signal, together with the appropriate relationships. A simple conformance measure might compare the required roles and relationships with those found in the actual portfolio. The research illustrates this through a pattern-coverage concept where satisfied required elements are compared with the total required elements.
A portfolio might satisfy the objective, use case, evidence and KPI roles while missing the feedback path. The system then reports that the portfolio matches most of the Decision pattern but lacks feedback closure. Another portfolio might have every required object but no relationship from the KPI to the business objective. A third might satisfy the structure while relying on a product whose SLO does not meet the requirements of the decision.
This produces much better guidance than assigning a generic health score. The pattern explains which expected part of the design is incomplete and why that matters.
Executable patterns also change how new portfolios are designed
The same pattern structure that validates an existing portfolio also helps when new demand enters. Take predictive maintenance again. A portfolio tool receives the business objective and use-case description and, instead of immediately generating a new set of data products, first identifies candidate patterns such as Entity, Signal-to-Action and Closed-Loop Decision Support. It then searches the existing portfolio for products and objects that satisfy the expected roles.
The research describes a possible flow where the tool finds an existing asset product, maintenance-history product, equipment taxonomy and telemetry stream. It also finds that no outcome KPI or feedback signal exists and that a proposed new sensor product strongly overlaps with the existing telemetry product. The resulting recommendation is to reuse the existing products, define the missing KPI and feedback signal, and decide whether an agent role is required.
This is materially different from using generative AI to fill a portfolio template. The pattern acts as a reasoning contract against the existing portfolio. Generation happens only after reuse, gaps and relationships have been examined.
That changes the order of work. Portfolio design begins with business context and pattern selection, continues through reuse analysis and gap detection, and creates new products only where the expected configuration requires capabilities that the portfolio does not already provide.
The SDK becomes the execution layer rather than the pattern itself
The Open Data Products SDK already provides capabilities around validation, generation, search, graph traversal, explanation, portfolio workflows and MCP interfaces. The research therefore recommends that a future pattern layer build on these capabilities instead of introducing a separate runtime. ODPR also provides a direction for declarative workflow contracts through concepts such as inputs, outputs, steps, validation gates, review requirements and run policy.
A future pattern-driven workflow might start from business context, identify candidate patterns, generate an ODPC role skeleton, search the portfolio for reusable products, run duplication and gap checks, create or reference required ODPS product definitions, generate ODPG relationships, validate the result and then move through human review before publication. The research proposes this as a future direction rather than current SDK behavior.
The same distinction applies to possible commands such as pattern match, pattern instantiate or pattern lint. Those names illustrate what a future command surface might look like. They are not released SDK commands today, and keeping that boundary explicit matters if this series is going to serve as a serious design proposal rather than product marketing.
The architectural relationship is simpler than the command examples suggest. Standards define the portfolio structures. Patterns encode reusable portfolio design knowledge. The SDK provides a place where those two might eventually meet in working tools.
AI agents gain a reasoning contract instead of another prompt
Machine-readable patterns become especially interesting when the portfolio itself is used as context for AI agents. Without explicit pattern knowledge, an agent asked to help design a portfolio has to infer what a good configuration looks like from instructions, examples and whatever context happens to be available in the prompt.
A machine-readable pattern changes that because the agent receives explicit roles, required relationships, design constraints and known anti-patterns while the actual portfolio graph is supplied separately. It is then able to compare the expected structure with the existing structure and explain its reasoning in portfolio terms.
For predictive maintenance, the agent might identify several matching patterns, find the existing products that satisfy their roles, detect that the feedback path is missing and flag a proposed product as an overlap candidate. It does not need to invent a complete portfolio because the pattern tells it what to look for and the graph tells it what already exists.
MCP’s separation between Resources and Tools fits this model well. Pattern definitions, catalog subsets, graph context and data product summaries fit naturally as resources. Validation, search, traversal, duplicate analysis and controlled generation fit as tools. The agent receives both design knowledge and bounded ways to act on that knowledge.
This also creates a better governance model than hiding portfolio design logic inside a large system prompt. Patterns are versioned artifacts. Their requirements are inspectable. Their evidence is visible. Their application to a portfolio is reviewable.
Evidence needs to travel with the pattern
Machine-readable patterns introduce one risk that deserves attention. Once patterns sit in a registry and appear in tools, every pattern begins to look equally authoritative even when some have been observed repeatedly and others are still hypotheses.
The research therefore proposes making evidence maturity part of the pattern definition. A pattern might move through states such as candidate, observed, validated and deprecated, while also recording sources, known applications and the date of the last review.
This is particularly important for the pattern families introduced in Part 2. The research provides conceptual grounding for Entity, Decision, Signal/Event and Reference patterns, while AI/Agent and Operational Monitoring might eventually prove to sit at a different level. Turning those candidates into YAML does not resolve that uncertainty. Machine readability should make the evidence easier to inspect rather than make an experimental pattern look settled.
The same applies to impact. The research did not identify a credible cross-industry dataset showing that organizations using particular portfolio patterns achieve higher reuse, lower duplication or better business outcomes. Those relationships still need empirical work. Real portfolio applications should gradually provide evidence around use-case coverage, adoption, duplication, SLO attainment, dependency risk and measurable outcomes.
A pattern registry should therefore preserve both design knowledge and the confidence we have in that knowledge.
Executable does not mean automatic
There is a useful boundary to keep as this idea moves from articles toward implementation. An executable pattern does not mean that software should make every portfolio decision automatically.
The pattern should make expected structure explicit. Tooling should search, compare, validate and explain. AI should help identify matches, gaps, overlap and consequences. Automation should handle deterministic work where appropriate. Portfolio owners still need to decide whether an apparent duplicate serves a legitimate regulatory variant, whether a missing feedback loop is acceptable during an early pilot, whether a shared product has become too central, or whether a candidate pattern fits the context at all.
This is consistent with the broader pattern tradition. A design pattern supports reasoning rather than replacing it, while machine readability makes that reasoning easier to repeat, inspect and embed into tools. That is enough to make the concept operational without turning portfolio architecture into rule execution.
The four-part argument comes together here
Across this series, the argument has moved through four levels. The first article treated the portfolio itself as a design problem because objectives, use cases, products, signals, KPIs, agents and dependencies create structures that are larger than individual products. The second proposed a first set of candidate pattern families around recurring portfolio problems. The third showed how the same structural view exposes gaps, duplication, semantic forks, dependency fragility and other anti-patterns.
This final step adds a machine-readable representation so that the knowledge captured by those patterns becomes testable against real portfolios. The pattern remains a description of recurring design knowledge. The Pattern Application connects it to one concrete situation. ODPC, ODPG and ODPS remain the portfolio truth. The SDK and related tooling provide the execution environment for search, validation, traversal, explanation and eventually pattern-guided workflows.
That leaves an interesting research and implementation agenda. Candidate patterns need real examples. Their recurrence needs evidence. Pattern relationships need refinement. Machine-readable definitions need experimentation. Portfolio telemetry needs to tell us whether recognizable configurations correlate with better reuse, stronger objective coverage, fewer duplicated capabilities, safer agent operation or clearer value measurement.
The idea started with a fairly simple observation: once data products form a portfolio, the portfolio itself becomes something we need to design. The next step is to stop keeping that design knowledge only in diagrams, documents and people’s heads.
