It fits the existing workflow.
The team declares the system’s context, describes its data with Croissant metadata and defines controls to treat its risks. Froga collects evidence from runs and the artifacts they produce to complete the technical documentation.
Declarations and observations
Declared by the team
- purpose of the system
- what it is for and whom it affects
- applicable standards
- the ones the team declares
- description of the data
- Croissant metadata: the dataset’s origin, structure and conditions of use
The description records what is declared; it does not verify the data itself.
Collected from the run
- Description of the model
- It draws on the components, artifacts and results available from each run. Its scope depends on the evidence collected.
The team decides how to treat each risk
The team identifies and assesses each risk and decides how to treat it: reduce it, accept it with justification, avoid it or transfer it. To put that treatment into practice, it defines the necessary controls and their acceptance criteria. Results and evidence inform the review of the treatment and reassessment of the remaining risk.
Each control specifies what is checked, the criterion and the supporting evidence. For a numerical check, the acceptance criterion includes a threshold.
The team defines separately how each result affects whether work continues.
- Identify
- Analyse
- Evaluate
- Treat
- Check
- Review residual risk
Fictional example · simulated figures
RSK-DEMO
Defects that escape inspection
- Declared impact
- High
- Declared likelihood
- Possible
Path to harm
One part type is underrepresented in the data.
The model detects its defects less reliably.
The part moves through the process without additional review.
- Consequence
- A defective part reaches assembly and compromises product quality.
- Risk treatment
- Reduce. Extend validation across part types and capture conditions; review uncertain cases before releasing the version.
Treatment controls
Defect detection rate. Each control retains its criterion, result and evidence.
C-01Overall detection
Meets the criterion
- Acceptance criterion
- ≥ 95%
- Simulated result
- 96%
Evidence: Overall evaluation of the test dataset.
C-02Detection by part type · worst group
Does not meet the criterion
- Acceptance criterion
- ≥ 90%
- Simulated result
- 82%
Evidence: Evaluation broken down by part type.
C-03Detection under adverse lighting
Not measured
- Acceptance criterion
- ≥ 90%
- Simulated result
- Not available
Evidence: These conditions have yet to be evaluated.
Scale 0–100%. Dashed line: threshold. Solid marker: simulated result. No marker: no measurement.
- Residual risk
- Awaiting reassessment
- Decision configured for this example
- Hold the version until the failing control is resolved and the missing measurement is completed.
Fictional visual inspection case: criteria and results are simulated, not client data or recommended thresholds. A passing control alone does not demonstrate that the risk has been treated.
Automated checks remain distinct from documented human reviews and evidence that does not yet support a conclusion. Recording a human assertion does not turn it into a measured or validated check.
Where it hooks in
Froga integrates with the organisation’s MLOps and DevSecOps layers to gather evidence for the technical documentation, through the available integrations.
Within the organisation
MLOps
Data versions, execution records and model metrics, according to what each tool provides.
Within the organisation
DevSecOps
Versioned code and continuous integration, where Froga verifies deliveries according to each connection’s capabilities.
Result in Froga
Technical documentation
Froga assembles and signs the evidence, linked to the data, model and documented controls.
What it works with
MLOps · data and executions
DVC
anchors the lock file; a third party recomputes it with the repository
MLflow
anchors the metrics digest; it lives in its own store
Dagster
anchors over its own material; it lives in its own store
DataLad
provenance in the history, data by pointer
DevSecOps · repositories and continuous integration
GitHub
verifies the delivery
GitLab
verifies the delivery
Forgejo
client: does not verify the delivery
What ends up signed
- risk and treatment
- documented justification
- dataset
- data lineage
- training algorithm
- run manifest
- metrics
- measured thresholds
- model
- signed provenance
What is delivered
The resulting technical documentation is what the team presents to the notified body. Coverage says, standard by standard, what it supports and what it does not.
And when there is no evidence to affirm or to deny, it says so. It does not paint it green.
See the coverage