Retention management system

Abstract

To provide a system, a method, and a non-transitory computer-readable medium which facilitate dynamic management of data retention.SOLUTION: A method includes the steps of: recording data records associated with point-of-sale (POS) transactions; subjecting the records to an evaluation based on data usage metrics including frequency of data access and timing of data access; processing these metrics using a computational model (e.g., a trained neural network) to quantitatively assess each record based on a composite metric; generating a data retention policy; and modifying storage of at least some of the data to comply with the data retention policy.SELECTED DRAWING: Figure 4

Description

[Background technology]

[0001]

[0001] Data retention remains a significant focus in various sectors, including retail. Within the retail business domain, a significant amount of data can be generated, ranging from inventory, sales metrics, customer interactions, transaction records, and the like. Traditional approaches to data retention typically utilize fixed or predefined settings that cannot be tailored to the attributes or usage patterns of the data. Moreover, retail personnel often lack formal training in data retention protocols, leading to variability and suboptimal practices. Such shortcomings can affect the allocation of storage resources, affect the timeliness and efficacy of data retrieval processes, and pose challenges to alignment with legal or organizational data retention guidelines.

[0002]

[0002] Throughout the drawings, reference numbers may be reused to indicate correspondence between referenced elements. The drawings are provided to illustrate embodiments of the present disclosure but not to limit the disclosure. [Brief description of the drawings]

[0003] [Figure 1]

[0003] A diagram showing one exemplary system architecture illustrating how data flows between retail operations, data storage, and a neural network trained to generate individually tailored data retention settings. [Diagram 2]

[0004] FIG. 1 illustrates an example of training a machine learning model, in accordance with the present disclosure. [Diagram 3]

[0005] FIG. 1 illustrates an example of applying a trained machine learning model to new observations relevant to determining data retention policies. [Figure 4]

[0006] 1 is a flow diagram illustrating one embodiment of a process for dynamic retention management. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004]

[0007] Some concepts of the present invention relate to dynamically managing how long various types of data are retained in a database before they are deleted or moved to remote storage. Traditionally, data retention parameters may be pre-established or manually configured by end users. However, in some settings, such as retail environments, where users may lack technical expertise, it may be difficult to determine suitable data retention settings. To alleviate these and other complexities, some concepts of the present invention dynamically adjust data retention settings while taking into account various data usage metrics, including, but not limited to, frequency of data access, timing of data access, nature of the data, or legal or organizational compliance requirements. Some concepts of the present invention span a level of granularity, allowing the system to ascertain and implement data retention settings that are uniquely suited to each data type, or even individual data records.

[0005]

[0008] Some of the inventive concepts may facilitate adaptive, real-time management of data retention, which may be advantageous in dynamic environments with changing data needs. For example, these inventive concepts may help to effectively manage limited server storage, reducing the risk of business interruptions due to server overload. In addition, dynamic adjustments to data retention settings may help to mitigate costs by reducing the amount of data stored and / or ensuring that the amount of data stored does not exceed storage limits, such as storage limits associated with storage tiers.

[0006]

[0009] 1 illustrates one embodiment of an environment 100 that includes a network 104, a point of sale (POS) system 110, a business data store 120, and a retention management system 130. In the illustrated embodiment, the retention management system 130 includes a metrics manager 132, a retention coordinator 134, and an application system 136. To simplify the discussion and not limit the disclosure, FIG. 1 illustrates only one POS system 110, business data store 120, retention management system 130, metrics manager 132, retention coordinator 134, and application system 136, although multiple may be used.

[0007]

[0010] Any of the aforementioned components or systems of the environment 100 may communicate over a network 104. The network 104 may enable transmission of data packets between components of the system, including the POS system 110, the business data store 120, the retention management system 130, the metrics manager 132, the retention coordinator 134, and / or the application system 136. Although only one network 104 is shown, there may be multiple different and / or distributed networks 104. The network 104 may include any type of communication network. For example, the network 104 may include one or more of a wide area network (WAN), a local area network (LAN), a cellular network, an ad-hoc network, a satellite network, a wired network, a wireless network, and the like. In some embodiments, the network 104 may include the Internet.

[0008]

[0011] Any of the aforementioned components or systems of environment 100, such as any one or any combination of POS system 110, business data store 120, retention management system 130, metrics manager 132, retention coordinator 134, and / or application system 136, may be implemented using combined or individual computing devices, processors, distributed processing systems, servers, isolated execution environments (e.g., virtual machines, containers, etc.), shared computing resources, etc. Additionally, any of the aforementioned components or systems of environment 100 may host or execute one or more client applications, which may include a web browser, a mobile application, a background process that performs various operations with or without direct interaction from a user, or a "plug-in" or "extension" to another application, such as a web browser plug-in or extension.

[0009]

[0012] The POS system 110 facilitates the execution of POS transactions and serves as a nexus for the generation and management of various data sets. The POS system 110 may be in communication with or may be incorporated into various hardware and software components, including, but not limited to, a processor, a memory storage unit, a barcode scanner, a receipt printer, a digital scale, a dimension analyzer, or a payment interface. The payment interface itself may include, but is not limited to, a magnetic stripe reader, a pin pad for secure payment entry, a signature capture device, or a biometric device. The POS system 110 may include a user interface, which may include elements such as a touch screen or a keyboard. The user interface may enable staff or customer interaction (e.g., self-checkout). These components may individually or collectively contribute to the completion and enhancement of the transaction process, thereby generating various types of data and complex matters.

[0010]

[0013] The POS system 110 is configured to generate, capture, and manage many facets of data, providing utility in various business areas. In the context of the types of data generated, the POS system 110 may generate transaction data that may include, but is not limited to, item identifiers, quantities, payment methods, or time markers. The POS system 110 may facilitate additional transaction activities, such as return processing or inquiry processing, thereby creating specialized sets of data related to these functions. In some cases, the POS system 110 may generate customer interaction data that may be derived from mechanisms such as loyalty or payment cards, providing insight into customer behavior and preferences. Inventory-related data may be continuously updated and may include metrics such as product availability, stock levels, or turnover. In some cases, an audit trail may be generated to log a subset of all transactions, thereby providing a data set for compliance or business review.

[0011]

[0014] The operational data store 120 stores a plurality of data records. Each data record in the data store may be associated with a corresponding data retention setting. The data retention setting may serve to dictate the period of time that the associated data record may be stored in the operational data store 120. Consequently, each data record may be associated with management criteria that may retain the data and outline its retention lifecycle in the operational data store 120. As described herein, the retention management system 130 may manage, generate, and apply the data retention settings, for example, in accordance with the data retention policy. The operational data store 120 may store one or more of a variety of data types. The data types may include, but are not limited to, transactional data, customer interaction data, promotional data, inventory data, or employee data.

[0012]

[0015] Transaction data may include information about individual or aggregate retail transactions. Transaction data includes, but is not limited to, item identifiers, quantities, payment methods, sales receipts, timing data related to transactions, and pricing information. Collectively, these elements contribute to a robust data set capable of meeting a diverse range of retail transaction requirements.

[0013]

[0016] Customer interaction data may include information regarding customer engagement. Customer interaction data may include information captured through mechanisms such as loyalty and payment cards. Additionally or alternatively, customer interaction data may span behavioral metrics such as frequency or timing of purchases. In some cases, some or all of the customer interaction data may be correlated with transactional data to establish an understanding of individual customer activities, including, but not limited to, identifying purchases for returns or other customer service activities.

[0014]

[0017] Promotional data may include information regarding past, ongoing, or upcoming retail promotions or sales. Promotional data may include, but is not limited to, metric indicators, timeline indicators, or performance indicators related to both ongoing and upcoming retail promotions. In some cases, promotional data may include information regarding the structure or timing of promotional campaigns. Additionally or alternatively, promotional data may include information regarding evaluation of promotional effectiveness through metrics such as customer engagement levels, sales lift, and return on investment.

[0015]

[0018] Inventory data may include information regarding a wide variety of real-time or non-real-time metrics related to inventory management, including, but not limited to, stock levels, turnover, and product availability, as well as additional salient factors such as seasonal demand changes and supplier lead times.

[0016]

[0019] Employee data may include a range of metrics or details related to workforce management. Employee data may include, but is not limited to, information regarding scheduling, working hours, or check-in and check-out times. Employee data may include a list of employees, including current and / or former employees. Employee data may include aggregate hours worked over a period of time, personnel identifiers such as names or employee numbers, or other personally identifiable information (PII). Employee data may include factors such as salary or wage amounts or the duration of an individual's employment with the company.

[0017]

[0020] The business data store 120 may be implemented as Amazon Simple Storage Service (S3), Elastic Block Storage (EBS) or cloud storage such as CloudWatch, Google Cloud Storage, Microsoft Azure Storage, InfluxDB, etc. The business data store 120 may be configured to provide high availability, high resiliency, low loss data storage. The business data store 120 may include Amazon CloudWatch metrics. In some cases, to provide higher availability, high resiliency, low loss data storage, the business data store 120 may store multiple copies of data within the same and different geographic locations and across different types of data stores (e.g., solid state, hard drive, tape, etc.). Additionally, once data is received at the business data store 120, the data may be automatically replicated multiple times to different data stores across the same and / or different geographic locations according to a replication factor. In some cases, the business data store 120 includes limited or fixed memory storage, such as 64GB, 128GB, 256GB, 1TB, etc.

[0018]

[0021] The retention management system 130 may be configured to dynamically manage the retention of data within the operational data store 120. The retention management system 130 may generate or update a data retention policy based on a variety of factors, including, but not limited to, regulatory compliance, business needs, frequency and timing of data access, nature and source of data, legal or organizational compliance requirements, storage utilization metrics, priority tags, file type, or file size. In some cases, these factors may contribute to a machine learning algorithm tasked with modifying or generating a data retention policy. By applying this data retention policy, the retention management system 130 may adjust retention settings associated with individual data records or sets of data records within the operational data store 120. Activities such as data deletion or mitigation may be performed in accordance with the data retention policy. Through these capabilities, the retention management system 130 may function to manage storage resource allocation, reduce operational costs, and ensure compliance with relevant regulatory standards. The retention management system 130 may include a metrics manager 132, a retention coordinator 134, and an application system 136.

[0019]

[0022] Metrics manager 132 collects and / or processes data usage metrics from operational data store 120. These metrics may include attributes such as, but not limited to, frequency and timing of data access, nature and source of data, storage usage metrics, priority tags, file types, or file sizes. The data usage metrics may be utilized to generate adapted data retention policies. In some embodiments, metrics manager 132 may be configured to pre-process these metrics to generate feature vectors that may be used to contribute to machine learning algorithms tasked with refining data retention policies to align with evolving business or regulatory requirements.

[0020]

[0023] Retention coordinator 134 can generate or update data retention policies based on metrics and / or feature vectors provided by metrics manager 132, and adjust data retention policies in response to the nature of currently stored data and evolving metrics. Data retention policies can be constructed to consider many factors, including, but not limited to, regulatory compliance, business needs, frequency and timing of data access, nature and source of data, legal or organizational compliance prerequisites, storage utilization metrics, priority tags, file types, or file sizes. In some embodiments, retention coordinator 134 can include or interface with machine learning algorithms designed for the iterative refinement of these data retention policies.

[0021]

[0024] Data retention policies may be employed to assign or associate data retention settings to data records. Data retention policies may include rules, criteria, or conditions governing the storage lifetime for each data record. Data retention policies may specify data retention settings for individual data records or sets of data records that dictate how long the data records should be retained in the business data store 120 before they are either deleted or moved to a remote storage facility. Data retention policies may be influenced by a variety of factors, including, but not limited to, regulatory compliance, business needs, frequency and timing of data access, nature and source of data, legal or organizational compliance requirements, storage utilization metrics, priority tags, file types, or file sizes. In some instances, these factors may contribute to machine learning algorithms tasked with modifying data retention policies to meet evolving organizational or regulatory requirements.

[0022]

[0025] Data retention policies may be based on business needs. For example, a business need may indicate a requirement for quick access to data records related to recent customer interactions. In some such cases, a data retention policy may indicate that these data records should be associated with data retention settings that facilitate quick retrieval.

[0023]

[0026] In some cases, data retention policies may be dictated by the frequency of data access and the timing of data access. For example, sales data may be most accessed at the end of a fiscal quarter. In some such cases, the data retention policy may indicate that these data records should be associated with data retention settings aimed at both long-term storage and quick access in time. As another example, frequent access to a data record may indicate its importance, which may suggest an extended storage period. In some such cases, the data retention policy may indicate that frequently accessed data records should be associated with data retention settings that allow for a longer storage lifetime. As another example, the data retention policy may be influenced by infrequent data access to dictate a shorter storage lifetime. For example, infrequent access may mean that the data is less important. In some such cases, the data retention policy may indicate that infrequently accessed data records should be associated with data retention settings that allow for a shorter storage lifetime.

[0024]

[0027] Data retention policies may be based on the nature and source of the data. For example, the nature of the data may include categories such as transaction data, customer data, or employee data, and the source may include an origin such as a POS system or an external database. In some such cases, the data retention policy may indicate that transaction data records from the POS system should be associated with data retention settings for extended storage lifetimes due to their criticality.

[0025]

[0028] The data retention policy may be based on regulatory compliance. For example, regulatory compliance may indicate that data records containing financial transactions must be retained for a minimum lifetime, such as seven years, to comply with tax regulations. In some such cases, the data retention policy may indicate that data records related to financial transactions should be associated with a data retention setting that corresponds to a seven-year storage lifetime.

[0026]

[0029] Data retention policies may be based on legal or organizational compliance requirements. For example, organizational compliance may require that employee data should not be stored beyond the term of employment. In some such cases, data retention policies may indicate that employee data records should be associated with data retention settings that facilitate deletion after the termination of employment. As an example, data records may be required to be retained for extended periods of time to comply with legal or business regulations. In some such cases, data retention policies may indicate that these data records should be associated with data retention settings that mandate a longer storage lifetime.

[0027]

[0030] In some cases, the data retention policy may be calibrated based on storage utilization metrics. For example, the storage utilization metrics may quantify that the business data store 120 has reached X% (e.g., 50%, 70%, 85%, 95%, 100%) of its total storage capacity. When the remaining storage capacity falls below a pre-specified threshold, e.g., 50%, 30%, 15%, 5%, 0%, the data retention policy may be operable to manage the allocation of storage resources in a more focused manner. Under such circumstances, the data retention policy may dictate that data records deemed as lower priority, defined by factors such as, for example, frequency of data access below a certain percentage, non-critical business role, or lack of high priority tags, should be associated with data retention settings for a shorter storage period. One example of this may be a data retention setting that mandates a 30-day automatic deletion cycle for these low priority data records. Conversely, data records that are categorized as higher priority, as defined by requirements such as elevated access frequency, critical business importance, or the presence of high priority or high sensitivity tags, may be associated with data retention settings designed for extended storage lifetimes.

[0028]

[0031] In some instances, data retention policies may be devised based on the presence of priority tags assigned to individual data records, sets of data records, or types of data records. These priority tags may act as qualifiers that mark data records with various levels of importance, sensitivity, or both. For example, a three-tiered priority tag system may be implemented, with a "high", a "medium", and a "low" tag. In scenarios where data records are tagged as "high priority", indicating attributes such as, but not limited to, critical business relevance, legal implications, or high access frequency, the data retention policy may specify that such records should be associated with a data retention setting that mandates a longer storage lifetime. This may translate to a data retention setting that exercises a multi-year storage period, coupled with a robust encryption protocol for added security. On the other hand, data records tagged as "low priority", which may indicate limited business utility or low sensitivity, may be associated with a data retention setting that prioritizes a shorter retention cycle, such as on the order of a few weeks to a few months. It will be appreciated that other tiered approaches, not limited to a three-tiered system, may be utilized to achieve similar objectives.

[0029]

[0032] In some cases, the data retention policy may take into account patterns of manual changes to data records of similar types. For example, if manual deletions are frequently applied to data records of a first type, this may be noted and replicated in the data retention policy. In some such cases, the data retention policy may indicate that data records of similar types should be associated with data retention settings that mimic these manual changes. As another example, if a data record has been recently modified or updated, it may be appropriately considered accordingly. In some such cases, the data retention policy may indicate that recently modified data records should be associated with data retention settings that allow for extended storage periods.

[0030]

[0033] In some cases, a data retention policy may be based on the obsolescence of data over a shorter storage lifetime. For example, old or irrelevant data may not require long-term storage. In some such cases, a data retention policy may indicate that old data records should be associated with data retention settings that facilitate a shorter storage period.

[0031]

[0034] In some cases, the data retention policy may take into account the transient nature of data over a shorter storage lifetime. For example, cache files or temporary files may be transient in nature. In some such cases, the data retention policy may indicate that data records of a transient nature should be associated with data retention settings that allow for shorter Time-to-Live (TTL) values.

[0032]

[0035] In some embodiments, data retention policies may be devised based on the file types associated with the data records. For example, data retention policies may recognize and categorize distinct file types contained within data records, thereby affecting the lifetimes for which these records may be stored. These file types may vary across embodiments, including, but not limited to, text files (.txt, .docx), image files (.jpg, .png), binary data (.bin), or more complex data structures such as relational databases (.sql). For example, text files, which are commonly used for trade records or regulatory compliance documentation, may be associated with data retention settings that may be associated with an extended storage lifetime. This extended storage lifetime may be due to long-term legal retention or business continuity needs. Conversely, image files, which are often linked to marketing materials or customer interactions, may be set for a shorter storage lifetime if they are found to have less lasting relevance. Thus, data retention policies may leverage the characteristics and / or common usage of each file type to dictate nuanced file-type-based data retention settings and manage storage lifetimes accordingly.

[0033]

[0036] In some cases, the data retention policy may be based on file size. Typically, parameters related to file size, expressed in units such as bytes, megabytes, or terabytes, may act as a factor influencing the storage lifetime for data records. When data records incorporate files that meet a first threshold, such as 500 megabytes, the data retention policy may stipulate that these records should be associated with a data retention setting that prioritizes a shorter storage lifetime. Such a shorter lifetime may be set, for example, to last for a period not exceeding three months to mitigate consumption of storage resources. Conversely, data records containing files that do not meet a second threshold, such as 50 megabytes, may be associated with a data retention setting that defines an extended storage period, potentially lasting more than one year. This methodological approach allows the business data store 120 to wisely allocate its storage capacity.

[0034]

[0037] In some cases, data retention policies may be based on data type. As mentioned, the operational data store 120 may store multiple data records. Each data record may be associated with one of multiple data types. These data types may be differentiated based on their functional attributes within a retail environment, such as the content of the data itself. For example, data types may include, but are not limited to, transaction types, customer interaction types, promotion types, inventory types, or employee types. In some cases, data retention policies may vary the duration for which different types of data are stored. For example, the policy may indicate a longer retention period for employee data compared to transaction data.

[0035]

[0038] The application system 136 may implement the data retention policies created by the retention coordinator 134 on the operational data store 120. By doing so, the application system 136 ensures that the data records in the operational data store 120 comply with the corresponding data retention policies. This capability allows for nuanced management of data that closely aligns with both business effectiveness and compliance with regulatory standards.

[0036]

[0039] In some cases, application system 136 may implement the data retention policy by interfacing with enterprise data store 120 through an application programming interface (API) or similar communication protocol. Upon receiving an updated or newly generated data retention policy, application system 136 may initiate a series of commands that modify metadata or tags associated with a data record or set of data records in enterprise data store 120. These metadata modifications dictate how and when the data should be managed, which may include activities such as deletion, archiving, or movement to a different storage tier. Application system 136 may employ validation mechanisms to confirm successful implementation of the new settings, thereby ensuring data integrity and compliance with policy objectives.

[0037]

[0040] 2 is a diagram 200 illustrating an example of training a machine learning model 211, according to the present disclosure. The training of the machine learning model 211 described herein may be performed using a machine learning system 300. The machine learning system 300 may include or be part of a computing device, server, cloud computing environment, etc., such as the POS system 110, the business data store 120, the retention management system 130, the metrics manager 132, the retention coordinator 134, and / or the application system 136 of FIG.

[0038]

[0041] As indicated by reference numeral 205, the machine learning model 211 may be trained using a set of observations. The set of observations may be obtained and / or input from historical data, such as data collected during one or more processes described herein. For example, the set of observations may include data collected from the POS system 110, the business data store 120, the retention management system 130, the metrics manager 132, the retention coordinator 134, and / or the application system 136, as described elsewhere herein. In some implementations, the machine learning system 300 may receive (e.g., as input) a set of observations from the POS system 110, the business data store 120, the retention management system 130, the metrics manager 132, the retention coordinator 134, the application system 136, or from a storage device.

[0039]

[0042] As illustrated by feature set 210, a feature set may be derived from a set of observations. A feature set may include a set of variables. A variable may be referred to as a feature. An observation may include a set of variable values ​​that correspond to the set of variables. A set of variable values ​​may be an observation. In some cases, different observations may be associated with different sets of variable values, which may be referred to as feature values.

[0040]

[0043] In some implementations, the machine learning system 300 may determine variables for a set of observations and / or variable values ​​for the observations based on inputs received from the POS system 110, the business data store 120, the retention management system 130, the metrics manager 132, the retention coordinator 134, and / or the application system 136. For example, the machine learning system 300 may identify a feature set (e.g., one or more features and / or corresponding feature values) from structured data input to the machine learning system 300, such as by extracting data from columns of a table, extracting data from fields of a form and / or message, and / or extracting data received within a structured data format. Additionally or alternatively, the machine learning system 300 may receive inputs from the POS system 110, the business data store 120, the retention management system 130, the metrics manager 132, the retention coordinator 134, the application system 136, or from an operator to determine the features and / or feature values.

[0041]

[0044] As an example, a feature vector for a set of data records may include a first feature related to the frequency of data access, a second feature related to the nature of the data, a third feature related to the source of the data, and so on. For example, the first feature may have a value of "quarterly" indicating data records that are frequently accessed at the end of a fiscal quarter. The second feature may be assigned a value such as "transaction" indicating the nature of the data, such as with respect to a business transaction. The third feature may have a value such as "POS system" as the source of these data records. These features and their values ​​are illustrative and may differ in other cases. For example, the feature vector may include one or more of the following features: storage utilization metrics, priority tags, regulatory compliance requirements, legal or organizational compliance prerequisites, file type, or file size. In some implementations, the retention coordinator 134, possibly interfacing with a machine learning algorithm, may perform preprocessing and / or dimensionality reduction to refine the feature vector to a minimum set of features. A machine learning model may be trained on this minimum feature set, thereby optimizing the computational and memory resources used for the iterative refinement of the data retention policy.

[0042]

[0045] As another example, a feature vector for a set of data records may include a first feature for data sensitivity, a second feature for data modification timestamps, and a third feature for user engagement level. The first feature may hold a value such as "sensitive" meaning that the data requires heightened security measures. The second feature may be assigned a timestamp indicating the last modified date and time of the data record, e.g., "2023-05-25 14:30:00". The third feature may include a numeric value, such as "7", representing the number of user interactions with that data record over a specified period of time.

[0043]

[0046] As another example, a feature vector for a type of data record may include a first feature representing a data owner identity, a second feature detailing the data format, and a third feature indicating a cloud storage provider. For example, the first feature may have a value such as "HR Department" indicating the ownership of the data. The second feature may hold a value such as "JSON" indicating the data format. The third feature may include a name such as "AWS S3" indicating the cloud storage server being used.

[0044]

[0047] A set of observations may be associated with a target variable 215. The target variable 215 may represent a variable having a numerical value (e.g., an integer or floating point value), may represent a variable having a numerical value that falls within a value range or has several distinct possible values, may represent a variable selectable from one of multiple options (e.g., one of multiple classes, classifications, or indications), or may represent a variable having a Boolean value (e.g., 0 or 1, true or false, yes or no), among other examples. A target variable may be associated with a target variable value, and a target variable value may be associated with an observation. In some cases, different observations may be associated with different target variable values.

[0045]

[0048] In the example 200, the target variable 215 is a retention setting. For example, the target variable 215 is a TTL. The TTL may define the life or duration of data in a system or network. The TTL may specify the duration a data record is retained before it is deleted or removed (e.g., automatically). The TTL setting may represent a variable having a numerical value, such as a unit of time, such as seconds, minutes, or days. The TTL may have a value within a predefined range or a set of discrete possible time intervals. In addition, the TTL may be selectable from a list of standardized retention options, such as short-term, medium-term, or long-term retention categories. Each data record may be paired with a unique TTL value that may be diverged among different records within a similar framework.

[0046]

[0049] In the example 200, the target variable 215 is an item identifier with a value of "120 days". However, the TTL setting may be configured with various values ​​depending on the nature of the data. For example, a "24 hours" TTL may be applied to transactional data that requires quick deletion after processing. For data with temporal importance, such as user session information, a "7 days" TTL value may be deemed suitable. In situations requiring compliance or archival needs, the TTL may be extended to a period such as "365 days" or even set to "infinite" to ensure long-term data storage. For data categories requiring conditional retention, a "pending manual review" TTL value may be established that will suspend automatic deletion until human intervention occurs. In some scenarios, the TTL value may be configured according to a mathematical function, for example, "TTL=f(x)", where "x" may represent a variable such as a user engagement metric or a data sensitivity rating.

[0047]

[0050] It will be appreciated that goal variables 215 may vary across embodiments within the concept of the present invention. For example, goal variables 215 may encompass a variety of other retention parameters other than TTL. These may include, but are not limited to, retention categories that dictate priority, deletion trigger events, storage tier designations, version numbers, geographic storage locations, encryption requirements, backup frequencies, designated data owners, audit flags, legal retention status, data classifications, content types, and expiration notification periods. Each of these variables may act as a separate goal variable, enabling fine-tuned data retention strategies adapted to meet organizational or regulatory needs.

[0048]

[0051] The target variable may represent a value that the machine learning model 211 is trained to predict, and the feature set may represent variables that are inputs to the trained machine learning model 245 to predict values ​​for the target variable. The set of observations may include target variable values ​​such that the machine learning model 211 may be trained to recognize patterns in the feature set 210 that result in the target variable value. Machine learning models that are trained to predict target variable values ​​may be referred to as supervised learning models or predictive models. When the target variable is associated with continuous target variable values ​​(e.g., a range of numbers), the machine learning model 211 may employ regression techniques. When the target variable is associated with categorical target variable values ​​(e.g., classes or labels), the machine learning model 211 may employ classification techniques.

[0049]

[0052] In some implementations, the machine learning model 211 may be trained on a set of observations that does not include a target variable (or that includes a target variable, but the machine learning model 211 has not been run to predict the target variable). This may be referred to as an unsupervised learning model, an automated data analysis model, or an automated signal extraction model. In this case, the machine learning model 211 can learn patterns from a set of observations without labeling or supervision and can provide output indicative of such patterns, such as by using clustering and / or association to identify related groups of items within the set of observations.

[0050]

[0053] As further shown, the machine learning system 300 may partition the set of observations into a training set 220 that includes a first subset of the observations of the set of observations and a test set 225 that includes a second subset of the observations of the set of observations. The training set 220 may be used to train (e.g., fit or tune) the machine learning model 211, and the test set 225 may be used to evaluate the machine learning model 211 trained using the training set 220. For example, in the case of supervised learning, the test set 225 may be used for initial model training using the first subset of the observations, and the test set 225 may be used to test whether the trained model accurately predicts the target variable in the second subset of the observations. In some implementations, the machine learning system 300 may partition the set of observations into the training set 220 and the test set 225 by including a first portion or percentage of the set of observations (e.g., 75%, 80%, or 85%, among other examples) in the training set 220 and a second portion or percentage of the set of observations (e.g., 25%, 20%, or 25%, among other examples) in the test set 225. In some implementations, the machine learning system 300 may randomly select observations to be included in the training set 220 and / or the test set 225.

[0051]

[0054] As indicated by reference numeral 230, the machine learning system 300 may train the machine learning model 211 using the training set 220. This training may include running, by the machine learning system 300, a machine learning algorithm to determine a set of model parameters based on the training set 220. In some implementations, the machine learning algorithm may include a regression algorithm (e.g., linear regression or logistic regression) that may include a regularized regression algorithm (e.g., lasso regression, ridge regression, or elastic net regression). Additionally or alternatively, the machine learning algorithm may include a decision tree algorithm that may include a tree ensemble algorithm (e.g., generated using bagging and / or boosting), a random forest algorithm, or a boosted tree algorithm. The model parameters may include attributes of the machine learning model 211 that are learned from the data entered into the model (e.g., the training set 220). For example, in the case of a regression algorithm, the model parameters may include regression coefficients (e.g., weights). In the case of a decision tree algorithm, the model parameters may include, as an example, a decision tree split location.

[0052]

[0055] As indicated by reference numeral 235, the machine learning system 300 may use one or more hyperparameter sets 240 to tune the machine learning model 211. Hyperparameters may include structural parameters that control the execution of the machine learning algorithm by the machine learning system 300, such as constraints applied to the machine learning algorithm. Unlike model parameters, hyperparameters are not learned from data input into the model. An exemplary hyperparameter for a regularized regression algorithm includes the strength (e.g., weights) of a penalty applied to the regression coefficients to mitigate overfitting of the machine learning model 211 to the training set 220. The penalty may be applied based on the size of the coefficient values ​​(e.g., for lasso regression, to penalize large coefficient values), based on the squared size of the coefficient values ​​(e.g., for ridge regression, to penalize large squared coefficient values), based on the ratio of size to squared size (e.g., for elastic net regression), and / or by setting one or more feature values ​​to zero (e.g., for automatic feature selection). Exemplary hyperparameters for decision tree algorithms include the tree ensemble technique to be applied (e.g., bagging, boosting, random forest algorithms, and / or boosted tree algorithms), the number of features to evaluate, the number of observations to use, the maximum depth of each decision tree (e.g., the number of splits allowed for a decision tree), or the number of decision trees to include within the random forest algorithm.

[0053]

[0056] To train the machine learning model 211, the machine learning system 300 can identify a set of machine learning algorithms to be trained (e.g., based on operator input identifying one or more machine learning algorithms and / or based on random selection of the set of machine learning algorithms) and can train the set of machine learning algorithms (e.g., independently for each machine learning algorithm in the set) using the training set 220. The machine learning system 300 can adjust each machine learning algorithm using one or more hyperparameter sets 240 (e.g., based on operator input identifying the hyperparameter set 240 to be used and / or based on randomly generating hyperparameter values). The machine learning system 300 can train the machine learning model 211 using a machine learning algorithm and a corresponding hyperparameter set 240. In some implementations, the machine learning system 300 can train multiple machine learning models to generate a set of model parameters for each machine learning model, where each machine learning model corresponds to a different combination of a machine learning algorithm and a hyperparameter set 240 for that machine learning algorithm.

[0054]

[0057] In some implementations, the machine learning system 300 may perform cross-validation when training the machine learning model 211. Cross-validation may be used to obtain a reliable estimate of the machine learning model performance using only the training set 220 and without using the test set 225, such as by splitting the training set 220 into several groups (e.g., based on an operator input identifying the number of groups and / or based on randomly selecting the number of groups) and using the groups to estimate the model performance. For example, using k-fold cross-validation, the observations in the training set 220 may be split (e.g., sequentially or randomly) into k groups. For the training procedure, one group may be marked as a hold-out group and the remaining groups may be marked as a training group. For the training procedure, the machine learning system 300 may train the machine learning model 211 on the training group and then test the machine learning model 211 on the hold-out group to generate a cross-validation score. The machine learning system 300 can repeat this training procedure using different holdout groups and different test groups to generate a cross-validation score for each training procedure. In some implementations, the machine learning system 300 may train the machine learning model 211 independently k times, with each individual group used once as a holdout group and k-1 times as a training group. The machine learning system 300 can combine the cross-validation scores for each training procedure to generate an overall cross-validation score for the machine learning model 211. The overall cross-validation score may include, for example, the average cross-validation score (e.g., across all training procedures), the standard deviation across the cross-validation scores, or the standard error across the cross-validation scores.

[0055]

[0058] In some implementations, the machine learning system 300 may perform cross-validation when training the machine learning model 211 by splitting the training set into several groups (e.g., based on an operator input identifying the number of groups and / or based on randomly selecting the number of groups). The machine learning system 300 may perform multiple training procedures and may generate a cross-validation score for each training procedure. The machine learning system 300 may generate an overall cross-validation score for each hyper-parameter set 240 associated with the machine learning algorithm. The machine learning system 300 may compare the overall cross-validation scores for different hyper-parameter sets 240 associated with the machine learning algorithm and select the hyper-parameter set 240 with the best (e.g., highest accuracy, lowest error, or closest to a desired threshold) overall cross-validation score to train the machine learning model 211. The machine learning system 300 may then train the machine learning model 211 using the selected hyper-parameter set 240 without cross-validation (e.g., using all of the data in the training set 220 without any holdout groups) to generate a single machine learning model 211 for the machine learning algorithm. The machine learning system 300 may then test this machine learning model 211 using the test set 225 to generate a performance score, such as the mean squared error (e.g., for regression), the mean absolute error (e.g., for regression), or the area under the receiver operating characteristic curve (e.g., for classification). If the machine learning model 211 performs properly (e.g., has a performance score that meets a threshold), the machine learning system 300 may store the machine learning model 211 as a trained machine learning model 245 to be used to analyze new observations, as described below with respect to FIG.

[0056]

[0059] In some implementations, the machine learning system 300 may perform cross-validation as described above for multiple machine learning algorithms, such as a regularized regression algorithm, a different type of regularized regression algorithm, a decision tree algorithm, or a different type of decision tree algorithm. Based on performing cross-validation for multiple machine learning algorithms, the machine learning system 300 may generate multiple machine learning models, where each machine learning model 211 has the best overall cross-validation score for the corresponding machine learning algorithm. The machine learning system 300 may then train each machine learning model using the training set 220 (e.g., without cross-validation) and test each machine learning model using the test set 225 to generate a corresponding performance score for each machine learning model. The machine learning model 211 may compare the performance scores for each machine learning model and select the machine learning model with the best (e.g., highest accuracy, lowest error, or closest to a desired threshold) performance score as the trained machine learning model 245.

[0057]

[0060] As indicated above, Fig. 2 is provided as an example. Other examples may differ from those described with respect to Fig. 2. For example, the machine learning model 211 may be trained using a process different from that described with respect to Fig. 2. Additionally or alternatively, the machine learning model 211 may employ a machine learning algorithm different from that described with respect to Fig. 2, such as a Bayesian estimation algorithm, a k-nearest neighbor algorithm, an apriori algorithm, a k-means algorithm, a support vector machine algorithm, a neural network algorithm (e.g., a convolutional neural network algorithm), and / or a deep learning algorithm.

[0058]

[0061] 3 illustrates an example of applying a trained machine learning model to new observations relevant to determining a data retention policy. The new observations may be input to a machine learning system 300, which stores a trained machine learning model 345. In some implementations, the trained machine learning model 345 may be the trained machine learning model 245 described above with respect to FIG. 2. The machine learning system 300 may be part of a computing device, server, or cloud computing environment, such as the retention management system 130 of FIG. 1.

[0059]

[0062] As indicated by reference numeral 310, the machine learning system 300 may receive a new observation or set of new observations 343 and input the new observations into the machine learning model 345. The new observations may include, for example, a first feature of “quarterly,” a second feature of “transactions,” a third feature of “POS system,” etc.

[0060]

[0063] The machine learning system 300 may apply the trained machine learning model 345 to the new observation to generate an output 350, such as a result indicating a retention setting. The type of output may depend on the type of machine learning model and / or the type of machine learning task being performed. For example, the output may include a predicted (e.g., estimated) value of the target variable (e.g., a value in a continuous range of values, a distinct value, an indication, a class, or a classification), such as when supervised learning is employed. Additionally or alternatively, the output may include information identifying a cluster to which the new observation belongs, such as when unsupervised learning is employed, and / or information indicating a degree of similarity between the new observation and one or more previous observations (e.g., which may have been the new observation originally input to the machine learning model 345 and / or the observation used to train the machine learning model). In some implementations, the output 350 includes an indication of a TTL setting. For example, the output may correspond to a period of time that a data record should be stored in the operational data store 120 before being removed or moved to other storage, based on the input features. Additionally, as described herein, in some cases, the output 350 includes a confidence value for the output.

[0061]

[0064] In some implementations, the trained machine learning model 345 may predict a value of "suboptimal data retention" with a high confidence level. Based on this prediction, the machine learning system 300 may provide recommendations to revise existing data retention policies or may automatically adjust these policies. Conversely, if the machine learning model predicts that the current data retention policies are effective with a high confidence level, the machine learning system 300 may continue to operate under the existing policies without modification.

[0062]

[0065] The concepts of the present disclosure significantly enhance the robustness of data management systems by employing trained neural networks to analyze large data sets. This helps ensure that data repositories remain up-to-date and accurate, which may contribute to improved efficiency and effectiveness of data analytics and management processes. The machine learning system 300 may enable recognition and / or identification of tens, hundreds, thousands, or millions of data points and / or variables across a similar range of observations. This reduces the time and computational resources required when compared to manual analysis methods, while increasing accuracy and consistency. While FIG. 3 serves as an illustrative example, other examples may differ from those described with respect to FIG. 3.

[0063]

[0066] 4 is a flow diagram illustrating one embodiment of a process 400 for dynamic retention management. Although generally described as being implemented by retention management system 130, it will be understood that the elements outlined with respect to process 400 may be implemented by one or more computing devices or components associated with environment 100, such as, but not limited to, POS system 110, business data store 120, metrics manager 132, retention coordinator 134, and / or application system 136. Thus, the following exemplary embodiment should not be construed as limiting.

[0064]

[0067] In block 402, the retention management system 130 stores data records in the storage system according to the first data retention policy. These data records may be a subset of the multiple data records stored in the storage system. The stored data records may relate to POS transactions occurring across one or more POS devices in the retail environment. Additionally or alternatively, the data records may relate to transaction data, customer interaction data, promotional data, inventory data, or employee data.

[0065]

[0068] The first data retention policy may be generated by the retention coordinator 134 using a process similar to that outlined herein, such as at blocks 406 and 408. For example, the first data retention policy may be generated taking into account various factors such as regulatory compliance, business needs, and storage utilization metrics, among others. Alternatively, the first data retention policy may be a default policy that potentially lacks customization for a particular operating environment. Activities such as data reduction or data movement may be performed according to the first data retention policy. By adhering to this policy, the retention management system 130 can manage storage resource allocation, reduce operational costs, and stay in compliance with applicable regulatory standards.

[0066]

[0069] At block 404, the retention management system 130 searches for data usage metrics associated with the plurality of data records stored in the operational data store 120. This search may be triggered by a variety of requirements, such as, but not limited to, a scheduled system scan, an ad-hoc request from an administrator, or an automated trigger based on a predefined threshold in the storage usage metrics. The data usage metrics may be determined or collected by the metrics manager 132 and may include attributes such as, but not limited to, frequency of data access, data record size, or transaction metadata.

[0067]

[0070] In some cases, the metrics manager 132 may employ techniques such as SQL queries, API calls, or other data extraction mechanisms that correspond to the underlying data storage architecture to extract these metrics from the operational data store 120. The extracted data usage metrics can serve multiple purposes. For example, the data usage metrics can be utilized for refinement of data retention policies by the retention coordinator 134. As another example, the data usage metrics can contribute to machine learning algorithms tasked with enhancing the efficiency and effectiveness of data retention policies, thereby aligning with organizational or regulatory requirements. As another example, the data usage metrics can inform actionable insights for improving storage resource allocation, thereby effectively reducing operational costs and aiding the retention management system 130 in ensuring compliance with relevant regulatory standards.

[0068]

[0071] In some cases, metrics manager 132 pre-processes data usage metrics to generate feature vectors that may enhance their utility in machine learning algorithms or other analytical processes aimed at refining data retention policies. The feature vectors may be further analyzed by retention coordinator 134 to adapt or update data retention policies based on evolving organizational needs or compliance requirements.

[0069]

[0072] In block 406, the retention management system 130 utilizes a computational model (e.g., a trained neural network) to process the data usage metrics. The computational model may be specialized to quantitatively evaluate the data usage metrics and / or the data records themselves. The evaluation may be based on a composite metric that may be derived from multiple attributes, including, but not limited to, data access frequency, data record size, or transaction metadata. The computational model may output a data retention setting for each data record or a set of data records collectively. The computational model may be trained on historical data that may encompass a variety of requirements, including, but not limited to, past retention policies, storage usage metrics, business needs, legal or organizational compliance prerequisites, frequency of data access, and timing of data access. This training allows the computational model to effectively analyze current metrics and feature vectors to generate new or refined data retention policies.

[0070]

[0073] At block 408, the retention management system 130 may generate a second data retention policy based on the output of the computational model. In some embodiments, the second data retention policy may serve as an augmentation or correction to an existing data retention policy, thereby allowing the system to dynamically adapt to new information or changes in the business environment. For example, if the computational model identifies a transition in the data access patterns that suggests a different storage lifetime is more optimal, the second data retention policy may be configured to adjust storage settings for the associated data records in the business data store 120. Alternatively, the second data retention policy may completely replace the previous data retention policy if substantial changes in business or regulatory conditions warrant such replacement.

[0071]

[0074] The generation of the second data retention policy may be coordinated by the retention coordinator 134 in conjunction with the computational model. In some cases, the retention coordinator 134 generates the second data retention policy by applying data retention settings generated by the computational model. In some cases, the computational model outputs / generates the second data retention policy. The application system 136 may implement the second data retention policy within the business data store 120 to ensure compliance with the new set of standards, rules, or conditions outlined in the second data retention policy.

[0072]

[0075] At block 410, the retention management system 130 may be configured to alter storage settings for a subset or all of the data records in the business data store 120 in accordance with a second data retention policy. Modifications to the storage settings may occur based on various criteria specified by this second data retention policy, which may differ from the previous or initial data retention policy. Such criteria may encompass factors such as regulatory compliance, business needs, frequency and timing of data access, nature and source of data, legal or organizational compliance requirements, storage utilization metrics, priority tags, file types, or file sizes, among others.

[0073]

[0076] Activities such as deleting, moving, or retaining data may be performed in accordance with a second data retention policy, thereby enabling the retention management system 130 to effectively manage storage resource allocation, minimize operational costs, and maintain compliance with relevant regulatory standards.

[0074]

[0077] It will be understood that the various blocks described herein may be implemented in various orders, and that the retention management system 130 may implement one or more of the blocks simultaneously and / or change the order, as desired. Additionally, it will be understood that fewer, more, or different blocks may be used as part of the routine 400.

[0075] [term]

[0078] Although the present disclosure has been described in the context of several cases and examples, those skilled in the art will understand that the present disclosure extends beyond the disclosed embodiments to other alternative embodiments and / or uses thereof, as well as obvious modifications and equivalents thereof. In addition, while several variations of the embodiments of the present disclosure have been shown and described in detail, other modifications that are within the scope of the present disclosure will be readily apparent to those skilled in the art. It is also contemplated that various combinations or subcombinations of the features and aspects of these embodiments may be made and still be encompassed within the scope of the present disclosure. For example, features described above with respect to one embodiment may be used with different embodiments described herein, and the combinations will still be encompassed within the scope of the present disclosure. It should be understood that various features and aspects of the disclosed embodiments may be combined with or substituted for one another to form various modes of the embodiments of the present disclosure. Thus, it is intended that the scope of the disclosure herein should not be limited by the embodiments described above. Thus, unless otherwise stated or clearly contradicted, each embodiment of the inventive concept may include, in addition to its essential features described herein, one or more features from each other embodiment of the inventive concept disclosed herein, as described herein.

[0076]

[0079] Features, materials, properties, or groups described with respect to an aspect, embodiment, or example should be understood to be applicable to any other aspect, embodiment, or example described in this chapter or elsewhere in this specification, unless inconsistent therewith. All of the features disclosed herein (including any accompanying claims, abstract, and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive. Protection is not limited to the details of any of the foregoing embodiments. Protection extends to any novel feature, or any novel combination of features disclosed herein (including any accompanying claims, abstract, and drawings), or to any novel step, or any novel combination of steps of any method or process so disclosed.

[0077]

[0080] Furthermore, some features described in the present disclosure in the context of separate implementations may be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as operating in some combinations, one or more features from a claimed combination may, in some cases, be removed from the combination, and the combination may be claimed as a subcombination or a variant of the subcombination.

[0078]

[0081] Moreover, although operations may be shown in the figures or described in the specification in a certain order, such operations need not be performed in the order or sequence shown, or all operations need not be performed to achieve a desired result. Other operations not shown or described may be incorporated into the example methods and processes. For example, one or more additional operations may be performed before, after, simultaneously with, or between the operations described. Furthermore, operations may be rearranged or reordered in other implementations. Those skilled in the art will appreciate that in some cases, the actual steps taken in the illustrated and / or disclosed processes may differ from those shown in the figures. Depending on the embodiment, some of the steps described above may be removed and others may be added. Furthermore, features and attributes of the above-disclosed embodiments may be combined in different ways to form additional embodiments, all of which are within the scope of the present disclosure. Also, it should be understood that the separation of various system components in the implementations described above should not be understood to require such separation in all implementations, and that the components and systems described may generally be incorporated together in a single product or packaged in multiple products.

[0079]

[0082] For the purposes of this disclosure, certain aspects, advantages, and novel features are described herein. Not all such advantages may necessarily be achieved according to any particular embodiment. Thus, for example, one skilled in the art will recognize that the present disclosure may be embodied or carried out in a manner that achieves one advantage or group of advantages as taught herein, without necessarily achieving other advantages that may be taught or suggested herein.

[0080]

[0083] Conditional terms such as "can," "could," "might," or "may," unless expressly stated otherwise or understood otherwise within the context in which they are used, are generally intended to convey that in some cases certain features, elements, and / or steps are included, while other embodiments do not include them. Thus, such conditional terms are generally not intended to imply that the features, elements, and / or steps are in any way required by one or more embodiments, or that one or more embodiments necessarily include logic for determining whether those features, elements, and / or steps are included or should be implemented in any particular embodiment, with or without user input or prompting.

[0081]

[0084] Conjunctions such as the phrase "at least one of X, Y, and Z," unless otherwise specified, are understood in the context in which they are otherwise generally used to convey that an item, term, etc. may be either X, Y, or Z. Thus, such conjunctions are generally not intended to imply requiring the presence of at least one of X, at least one of Y, and at least one of Z, in some instance.

[0082]

[0085] Words of degree as used herein, such as the terms "approximately," "about," "generally," and "substantially," refer to a value, amount, or characteristic that is close to a stated value, amount, or characteristic that still performs a desired function or achieves a desired result. For example, the terms "approximately," "about," "generally," and "substantially" can refer to an amount that is within less than 10%, less than 5%, less than 1%, less than 0.1%, and less than 0.01% of a stated amount. As another example, in some cases, the terms "generally parallel" and "substantially parallel" refer to a value, amount, or characteristic that deviates from being exactly parallel by no more than 15 degrees, 10 degrees, 5 degrees, 3 degrees, 1 degree, 0.1 degrees, or other angles.

[0083]

[0086] The scope of the present disclosure is not intended to be limited by the disclosure of preferred embodiments in this section or elsewhere herein, but may be defined by the claims presented in this section or elsewhere herein, or presented in the future. Claim language should be interpreted broadly based on the language employed in the claims, and should not be limited to the examples described herein or during prosecution of this application, which examples should be construed as non-exclusive.

Claims

1. storing, in a storage system according to a first data retention policy, a plurality of data records associated with POS transactions across one or more POS devices in a retail environment; retrieving data usage metrics for the set of data records, the data usage metrics comprising an indication of frequency of data access and timing of data access; processing the data usage metrics using a computational model that quantitatively evaluates each data record of the set of data records based on a composite metric derived from the frequency of data access and the timing of data access and outputs a data retention setting for each data type within the retail environment; generating a second data retention policy based on an output of the computational model; modifying storage of at least some of the set of data records based on the second data retention policy and storing subsequent data records in the storage system; A method comprising:

2. 2. The method of claim 1, wherein the frequency of data access is characterized by the number of read or write operations performed to each respective data record within a given time interval.

3. The method of claim 1 , wherein the timing of data access is characterized by a temporal profile indicating particular time intervals during which data is accessed.

4. 2. The method of claim 1, wherein the data usage metrics further comprise transaction metadata comprising a transaction timestamp, a POS device identifier, a customer identifier, or a product identifier associated with the POS transaction, and wherein the composite metric is further derived from the transaction metadata.

5. The method of claim 1 , wherein the data usage metrics further comprise a data record size attribute, and wherein the composite metric is further derived from the data record size attribute.

6. 2. The method of claim 1, wherein the second data retention policy reduces a retention lifetime for the first data record as compared to a corresponding retention lifetime specified by the first data retention policy for the first data record, wherein the reduction is based at least in part on a size of the first data record.

7. 2. The method of claim 1, further comprising retrieving storage utilization metrics characterized by at least one of available storage, used storage, or storage efficiency, and wherein the composite metric is further derived from the storage utilization metrics.

8. 2. The method of claim 1, further comprising: retrieving compliance-related data indicative of at least one of a legal policy or an organizational policy, wherein the composite metric is further derived from the compliance-related data such that data retention settings reflected by the second data retention policy are consistent with the at least one of the legal policy or the organizational policy.

9. 2. The method of claim 1, further comprising determining a pattern of manual modification, the pattern of manual modification characterized by a sequence of user-initiated modifications to data within a similar category, and wherein the composite metric is further derived from the pattern of manual modification.

10. 2. The method of claim 1, further comprising retrieving data staleness metrics characterized by an aging coefficient that quantifies the age or diminishing utility of a respective data record, and wherein the composite metric is further influenced by the data staleness metrics.

11. The method of claim 1 , wherein the computational model is a trained neural network.

12. 2. The method of claim 1 , wherein the first data retention policy and the second data retention policy each comprise a time-to-live (TTL) parameter for the set of data records, the TTL parameter indicating a time interval for at least one of automatic deletion or automatic transfer to a remote storage medium.

13. 2. The method of claim 1, wherein the plurality of data records comprises data records selected from the group consisting of order-related records, transaction-related records, payment-related records, entries in a receipt entry table, entries in an audit table, entries in a promotion table, item attribute records, or pricing records.

14. 2. The method of claim 1, wherein the data usage metrics comprise a timestamp indicating a last modification date of each data record, and the second data retention policy assigns data records having more recent modification dates to relatively longer retention periods.

15. 2. The method of claim 1, wherein the modifying comprises interfacing with the storage system through an application programming interface (API) to initiate a series of commands that modify metadata associated with the set of data records, wherein the metadata modifications dictate how or when data records should be deleted or moved to another storage system.

16. 1. A system comprising one or more processors, the processors comprising: storing, in a storage system according to a first data retention policy, a plurality of data records associated with POS transactions across one or more POS devices in a retail environment; retrieving data usage metrics for the set of data records, the data usage metrics comprising an indication of frequency of data access and timing of data access; inputting the data usage metrics into a computational model that quantitatively evaluates each data record of the set of data records based on a composite metric derived from the frequency of data access and the timing of data access and outputs a data retention setting for each respective data type within the retail environment; generating a second data retention policy based on an output of the computational model; modifying storage of at least some of the set of data records based on the second data retention policy and storing subsequent data records in the storage system; A system configured to:

17. The one or more processors: retrieving transaction metadata comprising a transaction timestamp, a POS device identifier, a customer identifier, or a product identifier associated with the POS transaction; retrieving a data record size attribute; retrieving storage utilization metrics, the storage utilization metrics being characterized by at least one of available storage, used storage, or storage efficiency; [0023] 20. The method according to claim 1, further comprising:

20. The system of claim 16, wherein the composite metric is further derived from the transaction metadata, the data record size attributes, and the storage utilization metrics.

18. 17. The system of claim 16, wherein the one or more processors are further configured to search for compliance-related data indicative of at least one of a legal policy or an organizational policy, and wherein the composite metric is further derived from the compliance-related data such that the data retention settings reflected by the second data retention policy are consistent with the at least one of the legal policy or the organizational policy.

19. 17. The system of claim 16, wherein the one or more processors are further configured to determine a pattern of manual modification, the pattern of manual modification characterized by a sequence of user-initiated modifications to data within a similar category, and wherein the composite metric is further derived from the pattern of manual modification.

20. A non-transitory computer-readable medium comprising computer-executable instructions that, when executed by one or more processors, cause the one or more processors to: storing, in a storage system according to a first data retention policy, a plurality of data records associated with POS transactions across one or more POS devices in a retail environment; retrieving data usage metrics for the set of data records, the data usage metrics comprising an indication of frequency of data access and timing of data access; inputting the data usage metrics into a computational model that quantitatively evaluates each data record of the set of data records based on a composite metric derived from the frequency of data access and the timing of data access and outputs a data retention setting for each respective data type within the retail environment; generating a second data retention policy based on an output of the computational model; modifying storage of at least some of the set of data records based on the second data retention policy and storing subsequent data records in the storage system; A non-transitory computer-readable medium for causing

Images