Add links

    Product and Model Oversight & Management

    From The Foundation for Best Practices in Machine Learning
    Organisation Best Practices > Product and Model Oversight & Management


    Hint
    To view additional information and to make edit suggestions, click the individual items.

    Product and Model Oversight & Management

    Objective
    To (a) identify possible risks for protected classes of persons, animals and the natural environment; and (b) minimise the unequal distribution of Products and Models errors to prevent reinforcing and/or deriving social inequalities and/or ills.


    5.1. Fairness & Non-Discrimination

    Objective
    To (a) identify possible risks for protected classes of persons, animals and the natural environment; and (b) minimise the unequal distribution of Products and Models errors to prevent reinforcing and/or deriving social inequalities and/or ills.
    Item nr. Item Name and Page Control Aim
    5.1.1. Fairness Policy

    A Policy and Guide, which promotes Product Fairness in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Fairness of Machine Learning.

    5.1.2. Product Fairness Procedures

    A set of Procedures to operationalise the Fairness Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the Fairness of Products and Models.

    5.1.3. Fairness Assessments

    Products should regularly complete Fairness assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Fairness and non-discrimination at regular intervals within the Product Lifecycle and Workflow Description.

    5.1.4. Review of the Fairness Policy

    The Fairness Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Fairness Policy is kept up-to-date.

    5.1.5. Review of Product Fairness Procedures

    Product Fairness Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Product Fairness Procedures are kept up-to-date.

    5.2. Data Quality

    Objective
    To ensure Data Quality and prevent unintentional effects, changes and/or deviations in Products and Models outputs associated with poor Product data.
    Item nr. Item Name and Page Control Aim
    5.2.1. Data Quality Policy

    A Policy and Guide, which describes the assessment and remediation of an Organisation's Data Quality. Chapters relating to (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived and included by Data Science Managers and approved by the Managerial Committee.

    To ensure the Data Quality of Machine Learning.

    5.2.2. Product Data Quality Procedures

    A set of Procedures to operationalise the Data Quality Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the Data Quality of Products and Models.

    5.2.3. Data Quality Assessments

    Products should regularly complete Data Quality assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Data Quality at regular intervals within the Product Lifecycle and Workflow Description.

    5.2.4. Review of the Data Quality Policy

    The Data Quality Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Data Quality Policy is kept up-to-date.

    5.2.5. Review of Product Data Quality Procedures

    Product Data Quality Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Product Data Quality Procedures are kept up-to-date.

    5.3. Representativeness & Specification

    Objective
    To (a) ensure that Product data and Models are representative of, and accurately specified for, target environments as far as is reasonably practical; and (b) guard against unintentional Products and Models behaviours and outputs as far as is reasonably practical.
    Item nr. Item Name and Page Control Aim
    5.3.1. Representativeness & Specification Policy

    A Policy and Guide, which promotes Representativeness and Specification in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Representativeness and Specification of Machine Learning.

    5.3.2. Product Representativeness & Specification Procedures

    A set of Procedures to operationalise the Representativeness & Specification Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the Representativeness and Specification of Products and Models.

    5.3.3. Representativeness & Specification Assessments

    Products should regularly complete Representativeness & Specification assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Representativeness and Specification at regular intervals within the Product Lifecycle and Workflow Description.

    5.3.4. Review of the Representativeness & Specification Policy

    The Representativeness & Specification Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Representativeness & Specification Policy is kept up-to-date.

    5.3.5. Review of Product Representativeness & Specification Procedures

    Product Representativeness & Specification Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Representativeness & Specification Procedures are kept up-to-date.

    5.4. Performance Robustness

    Objective
    To warrant Model outcomes and prevent unintentional Model behaviour a priori under operational conditions as far as is reasonably practical.
    Item nr. Item Name and Page Control Aim
    5.4.1. Performance Robustness Policy

    A Policy and Guide, which promotes Product Performance Robustness in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Performance and Robustness of Machine Learning.

    5.4.2. Product Performance Robustness Procedures

    A set of Procedures to operationalise the Performance Robustness Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions .

    To ensure the Performance Robustness of Products and Models.

    5.4.3. Performance Robustness Assessments

    Products should regularly complete Performance Robustness Assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Performance Robustness at regular intervals within the Product Lifecycle and Workflow Description.

    5.4.4. Review of the Performance Robustness Policy

    The Performance Robustness Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Performance Robustness Policy is kept up-to-date.

    5.4.5. Review of Product Performance Robustness Procedures

    Product Performance Robustness Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Performance Robustness Procedures are kept up-to-date.

    5.5. Monitoring & Maintenance

    Objective
    To ensure that Products and Models remain within acceptable operational bounds.
    Item nr. Item Name and Page Control Aim
    5.5.1. Monitoring & Maintenance Policy

    A Policy and Guide, which promotes Product monitoring and maintenance in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the monitoring and maintenance of Machine Learning.

    5.5.2. Product Monitoring & Maintenance Procedures

    A set of Procedures to operationalise the Monitoring & Maintenance Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the monitoring and maintenance of Products and Models.

    5.5.3. Monitoring & Maintenance Assessments

    Products should regularly complete Monitoring & Maintenance assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product monitoring and maintenance at regular intervals within the Product Lifecycle and Workflow Description.

    5.5.4. Review of the Monitoring & Maintenance Policy

    The Monitoring & Maintenance Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Monitoring & Maintenance Policy is kept up-to-date.

    5.5.5. Review of Product Monitoring & Maintenance Procedures

    Product Monitoring & Maintenance Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Monitoring & Maintenance Procedures are kept up-to-date.

    5.6. Explainability

    Objective
    To ensure Products and Models functions and outputs are explainable and justifiable as far as is practically reasonable.
    Item nr. Item Name and Page Control Aim
    5.6.1. Explainability Policy

    A Policy and Guide, which promotes Product Explainability in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Explainability of Machine Learning.

    5.6.2. Product Explainability Procedures

    A set of Procedures to operationalise the Explainability Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the Explainability of Products and Models.

    5.6.3. Explainability Assessments

    Products should regularly complete Explainability assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Explainability at regular intervals within the Product Lifecycle and Workflow Description.

    5.6.4. Review of the Explainability Policy

    The Explainability Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Explainability Policy is kept up-to-date.

    5.6.5. Review of Product Explainability Procedures

    Product Explainability Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Product Explainability Procedures are kept up-to-date.

    5.7. Safety & Security

    Objective
    To (a) prevent adversarial actions against, and encourage graceful failures for, Products and/or Models; (b) avert malicious extraction of Models, data and/or intellectual property; (c) prevent Model based physical or irreparable harms; and (d) prevent erosion of trust in outputs or methods.
    Item nr. Item Name and Page Control Aim
    5.7.1. Safety & Security Policy

    A Policy and Guide, which promotes Product Safety & Security in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Safety of Machine Learning.

    5.7.2. Product Safety Procedures

    A set of Procedures to operationalise the Safety Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions .

    To ensure the Safety of Products and Models.

    5.7.3. Safety Assessments

    Products should regularly complete Safety assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Safety at regular intervals within the Product Lifecycle and Workflow Description.

    5.7.4. Review of the Safety Policy

    The Safety Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Safety Policy is kept up-to-date.

    5.7.5. Review of Product Safety Procedures

    Product Safety Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Product Safety Procedures are kept up-to-date.

    5.8. Human-Centric Design & Redress

    Objective
    To ensure (a) building desirable solutions; (b) human control over Products and Models; and (c) that individuals affected by Products and Models outputs can obtain redress.
    Item nr. Item Name and Page Control Aim
    5.8.1. Human-centric Design & Redress Policy

    A Policy and Guide, which promotes Product Human-Centric Design & Redress in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Human-Centric Design & Redress of Machine Learning.

    5.8.2. Product Human-Centric Design & Redress Procedures

    A set of Procedures to operationalise the Human-Centric Design & Redress Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the Human-Centric Design & Redress of Products and Models.

    5.8.3. Human-Centric Design & Redress Assessments

    Products should regularly complete Human-Centric Design & Redress assessments according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Human-Centric Design & Redress at regular intervals within the Product Lifecycle and Workflow Description.

    5.8.4. Review of the Human-Centric Design & Redress Policy

    The Human-Centric Design & Redress Policy should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Human-Centric Design & Redress Policy is kept up-to-date.

    5.8.5. Review of Product Human-Centric Design & Redress Procedures

    Product Human-Centric Design & Redress Procedures should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Product Human-Centric Design & Redress Procedures are kept up-to-date.

    5.9. Systemic Stability

    Objective
    To prevent (in)direct adverse social and environmental effects as a consequence of interactions amongst Products, Models, the Organisation, and the Public.
    Item nr. Item Name and Page Control Aim
    5.9.1. Systemic Stability Policy

    A Policy and Guide, which promotes awareness and control of systemic effects and interactions in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Systemic Stability of Machine Learning.

    5.9.2. Product Systemic Stability Procedures

    A set of Procedures to operationalise the Systemic Stability Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the Systemic Stability of Products.

    5.9.3. Systemic Stability Assessments

    Products should regularly complete Systemic Stability according to Product Lifecycle and Workflow Descriptions to the extent that is reasonably practical. Assessment findings ought to be documented by the Product Team and reviewed by Data Science Managers and, when relevant, the Management Committee.

    To analyse, test, and report the risks identified with, and measures taken to ensure, Product Systemic Stability at regular intervals within the Product Lifecycle and Workflow Description.

    5.9.4. Review of the Systemic Stability Policy

    Systemic Stability should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Systemic Stability Policy is kept up-to-date.

    5.9.5. Review of Systemic Stability Procedures

    Product Systemic Stability should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Product Systemic Stability Procedures are kept up-to-date.

    5.10. Product Traceability

    Objective
    To ensure the clear and complete Traceability of Products, Models and their assets (inclusive of, inter alia, data, code, artifacts, output, and documentation) for as long as is reasonably practical.
    Item nr. Item Name and Page Control Aim
    5.10.1. Product Traceability Policy

    A Policy and Guide, which promotes Product Traceability during and after - (a) Product Definitions and Product design, development, and implementation; (b) data processing; and (c) Model design, development, training, and output ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure the Product Traceability of Machine Learning.

    5.10.2. Product Traceability Procedures

    A set of Procedures to operationalise the Traceability Policy should be developed and implemented within Products in light of Product Definitions, the Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure the Product Traceability of Products.

    5.10.3. Review of the Product Traceability Policy

    The Product Traceability should be reviewed periodically, or if significant changes occur, by Data Science Managers to ensure its continued effectiveness, suitability, and accuracy.

    To ensure that the Product Traceability Policy is kept up-to-date.

    5.10.4. Review of Product Traceability Procedures

    Product Product Traceability should be reviewed periodically, or if significant changes occur, by the Product Team to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Product Product Traceability Procedures are kept up-to-date.

    5.11. Product Decision-Making

    Objective
    To ensure that Product decision-making is done in a clear, informed, unbiased and collaborative manner with a diversity of Organisation opinions, when relevant.
    Item nr. Item Name and Page Control Aim
    5.11.1. Product Decision-Making Policy

    A Policy which promotes Product decision-making clarity in - (a) Product Definitions and Product design, development, and implementation; (b) data processing; (c) Model design, development, training, and output; and (d) consideration for the Product Risk Classification Portfolio ought to be derived by Data Science Managers and approved by the Managerial Committee.

    To ensure Product decisions - (a) are based on all available information, inclusive of those derived from Policies and Procedures of this document; (b) follow from and are aligned with the Product Lifecycle and Workflow Description; and (c) are made with reasonable care to avoid cognitive bias.

    5.11.2. Product Decision-Making Procedures

    A set of Procedures to operationalise the Decision-Making Policy within Products should be developed and implemented, inclusive of consultations with Business Stakeholders.

    To ensure clear, informed, unbiased and collaborative decision-making in Products.

    5.11.3. Product Decision-Making Diversity

    A diversity of Organisation stakeholder and Business Stakeholder opinions and input should be obtained, considered and, when relevant, weighed when making material Product decisions

    To ensure a diversity of opinions when making material Product decisions.

    5.11.4. Product Decision-Making Documentation

    Product decisions should be documented, indexed, stored and, when relevant, reviewed.

    To ensure that Product decisions are documented and indexed to warrant their effective management and oversight.

    5.12. Product Capabilities

    Objective
    To ensure that Products have sufficient capacity and capabilities to meet Product Definitions.
    Item nr. Item Name and Page Control Aim
    5.12.1. Financial Resource Allocation

    Sufficient financial resources ought to be allocated to Products based on their Product Definitions, Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure that Products have sufficient financial resources to allow for their success.

    5.12.2. Human Resource Allocation

    Sufficient human resources ought to be allocated to Products based on their Product Definitions, Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure that Products have sufficient human resources to allow for their success.

    5.12.3. Assets Allocation

    Sufficient Assets ought to be allocated to Products based on their Product Definitions, Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure that Products have sufficient Assets to allow for their success.

    5.12.4. Software Allocation

    Sufficient Software ought to be allocated to Products based on their Product Definitions, Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure that Products have sufficient Software to allow for their success.

    5.12.5. Knowledge & Development

    Product Teams should receive sufficient training and development based on the Product Definitions, Product Risk Classification Portfolio, and the Product Lifecycle and Workflow Descriptions.

    To ensure that Product Teams have sufficient training and development to allow for their success.

    5.12.6. Review of Product Capabilities

    Product resource allocation ought to be periodically reviewed, or if significant changes occur, by Data Science Managers, in consultation with Product Owners, to ensure their continued effectiveness, suitability, and accuracy.

    To ensure that Products resources are sufficiently maintained.

    5.13. Product Record

    Objective
    To promote the documentation and recording of Product, Product Team and employees tasks, deliverables and progress.
    Item nr. Item Name and Page Control Aim
    5.13.1. Product Record

    A clear and detailed Product record should be continually kept of Product design, development, implementation, deliverables, progress and employee tasks.

    To ensure that a clear Product record is kept to warrant effective oversight, management and accountability.

    5.13.2. Employee and Product Team Documentation

    Employee and Product Team processes ought to promote the documentation of Product tasks, discussions and deliverables when relevant and as much as is reasonably practical.

    To ensure that sufficient documentation is kept to warrant effective oversight, management and accountability.

    5.13.3. Log of User Access

    A formal log of user access rights to Products should be maintained and reviewed at regular intervals by Product Owners.

    To ensure the management, integrity and review of user access.

    5.13.4. Event Logs

    Event logs of Product user activities, exceptions, and faults should be produced, kept and regularly reviewed by Product Owners.

    To formally index and manage user activities to maintain Product oversight and integrity.

    Retrieved from "https://wiki.fbpml.org/w/index.php?title=Product_and_Model_Oversight_%26_Management&oldid=874"