Centralized Model Repository for Metadata and Output Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing predictive and descriptive modeling systems lack a centralized, structured approach for storing and managing metadata and outputs, leading to inefficiencies in model deployment, retrieval, and integration, with ad-hoc database structures required for new models and tacit knowledge dispersed across networks.

Innovation Solution

A computer-implemented method and system for storing model metadata and outputs in a centralized repository, using a model instance identifier to track executions and store outputs, facilitating consistent retrieval and integration, and enabling real-time score management and analysis.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If ad-hoc database structures are used for new models, then flexibility in storing different model types is improved, but system complexity and deployment time increase

Engineering Contradiction:
Improveflexibility in storing different model typesVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal repository structure that can store metadata and outputs for multiple types of models (predictive, descriptive, prescriptive) using a single standardized schema. The repository accepts various model types through a common interface, eliminating the need for separate ad-hoc database structures for each model type while maintaining flexibility.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system segments model management into distinct modular components: a centralized repository for metadata storage, separate execution environments for different model types, and standardized interfaces for data input/output. This segmentation allows the repository to maintain a simple, consistent structure while the execution layer handles the complexity of different model implementations.

Inventive Principle:
Principle #1Segmentation

2Reliability

If centralized repository is implemented, then consistency in model output retrieval is improved, but initial implementation complexity increases

Engineering Contradiction:
Improveconsistency in model output retrievalVSAvoidimplementation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces a standardized metadata schema as an intermediary layer between diverse model outputs and the centralized repository. This schema acts as a mediator that translates various model output formats into a unified structure, enabling consistent retrieval while simplifying the implementation by providing a clear translation framework.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system creates standardized templates for model metadata and output structures that can be copied and reused across different model types. Instead of creating unique database structures for each model, the system copies and adapts proven templates, reducing implementation complexity while ensuring consistency.

Inventive Principle:
Principle #26Copying

3Loss of time

If standardized storage method is used, then deployment time is reduced, but flexibility for new model types decreases

Engineering Contradiction:
Improvedeployment timeVSAvoidflexibility for new model types
Core Design Contradiction:
Loss of timeVSAdaptability or versatility

Solution Approach 1:

The patent implements a dynamic metadata schema that can adapt to new model types while maintaining structural consistency. The standardized repository structure includes flexible fields and configurable parameters that can be dynamically adjusted to accommodate emerging model types without requiring changes to the core repository architecture, thus reducing deployment time while preserving flexibility.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system uses parameterized metadata structures where key characteristics can be changed without altering the fundamental storage schema. New model types are accommodated by modifying parameters such as data types, field names, and validation rules within the standardized framework, enabling rapid deployment while maintaining structural flexibility.

Inventive Principle:
Principle #35Parameter changes

4Productivity

If model metadata and outputs are stored separately, then retrieval efficiency is improved, but data integration complexity increases

Engineering Contradiction:
Improveretrieval efficiencyVSAvoiddata integration complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent merges the storage of model metadata and outputs into a unified centralized repository while maintaining logical separation through standardized schemas. This integration allows efficient retrieval through single-query operations while the standardized structure simplifies data integration by providing consistent formats and relationships between metadata and outputs.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The repository structure is designed to universally handle both metadata and outputs using the same storage and retrieval mechanisms. This multi-functional approach eliminates the need for separate retrieval systems while maintaining efficiency, as the same standardized interface and query methods work for both metadata and output data.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS11232243B1System and method for employing model repository
Publication Date: 2022.01.25 NATIONWIDE MUTUAL INSURANCE CO
  • US11232243B1 patent drawing
  • US11232243B1 patent drawing
  • US11232243B1 patent drawing

AI summary

Model metadata for each of a plurality of models is stored. The model metadata includes a statistical analysis technique identifier and one or more model input data identifiers. A request to execute a model is received. The request includes data identifying one of the plurality of models, and a model execution start date and end date. On the model execution start date, execution of the model associated with the model execution request is commenced. Outputs of the executed model are stored in a database. The outputs are associated with a model instance identifier, information describing a context for execution of the model, and model output type information. The outputs are retrieved, using the model instance identifier, for analysis.