Know every AI system your department runs, in the register's own format
Start from the public Government of Canada AI Register, add the governance fields it lacks, and keep one record per system that owners maintain and auditors trust. Tovris imports the register, reports what is missing and exports it back in the published format.
- Who uses it
- Admin · Owner
- Instruments
- GC AI Register · AIA
- Starts when
- You import the register or add a system
- In the console
- AI systems
- Register entries imported, 0 failures
- 412
- Organizations in the published register
- 43
- Published fields, kept under their own names
- 24
From the build and the simulated Government of Canada test environment · synthetic data
Where the usual process breaks
Departments are expected to know which AI systems they run and what each one is for. In practice the list lives in several spreadsheets with different columns, and nobody can say which one is current.
- 01
The published register has no field for owner, impact level or risk tier, so governance data lives somewhere else.
- 02
Blank statuses and spelling variants make simple questions, like how many systems are in production, hard to answer.
- 03
Impact levels are worked out in a separate questionnaire and copied by hand, if at all.
- 04
When a record changes, there is no history of who changed what.
Four steps, each one a screen and an API route
Each step is part of the product, and each is written to the audit log as it happens.
- 01
Import the register
Load the GC AI Register CSV as published. Tovris keeps the original file, handles its encoding, and can run the import again without creating duplicates.
- 02
Read the quality report
The data-quality report lists blank statuses, spelling variants and missing personal-information flags, on screen and as a CSV.
- 03
Add governance fields
Owners fill in what the register lacks: owner, intended use, whether the system supports an administrative decision, risk tier and lifecycle stage.
- 04
Set the impact level
Complete the AIA questionnaire for the system. The final version sets its impact level, which decides the requirements that apply.
registry import
Register CSV
as published
Import
safe to re-run
Quality report
screen · CSV
Governance fields
owner fills in
AIA
level I to IV
What you can show
One registry that answers the inventory question directly, and that the rest of Tovris builds on.
A record per system with the register's 24 fields and the governance fields beside them.
A versioned history of every record: who changed which field, and when.
An AIA answer set per system, with draft and final versions.
An export in the register's own CSV or JSON format, ready to publish or import again.
In the console
- AI systems: list, filters and detail
- Imports and data-quality report
- AIA questionnaire on each system
Through the API
- POST /api/v1/systems/import
- GET /api/v1/systems
- GET /api/v1/systems/export
Instruments in scope
Who does what
Admin · Owner. Every action is checked against the person’s role on the server and written to the audit log.
The rest of the loop
Assessment
Assess each system against the DADM, with evidence a reviewer can check
Tovris works out which requirements of the Directive on Automated Decision-Making apply to a system, checks each one against the evidence you linked, and returns one of five results with a confidence score and citations. A person reviews every finding before it counts.
Assessor · Reviewer · DADM · AIA · PSD
- DADM 2025 requirements apply at level III
- 39 of 45
- Samples per requirement behind each confidence score
- 3
- Possible results, including “unable to determine”
- 5
Policy change
When a directive is amended, see every system it affects before you publish
Tovris compares the old and new editions requirement by requirement, shows which systems each change affects and why, and opens reassessment tasks for the systems already assessed. Only the changed requirements are assessed again.
Admin · Owner · DADM 2023 → 2025
- Requirements added by the June 2025 DADM amendments
- 11
- Requirements modified
- 34
- Requirements retired
- 6
Risk monitoring
Catch drift and unfair outcomes between assessments
Tovris watches data quality, input drift and output measures for each system. When a measure crosses its line, the result is filed as evidence, findings are raised on the linked requirements, a reassessment task opens, and your ticketing system hears about it.
Owner · Assessor · DADM 6.3
- Default drift alert line (Population Stability Index)
- 0.2
- Injected breaches caught in testing, no false alarms
- 2 of 2
- Ticket priorities on the signed webhook
- P1–P4
Walk through this on synthetic data
We run this use case end to end on the simulated Government of Canada environment, in English or French, and answer questions as we go.
Live walkthrough · English or French · Synthetic data only