What data does Mattilsynet actually require each week, and where does it live?
Mattilsynet requires every Norwegian sea site to report the average number of adult female lice per fish weekly, plus sea temperature and any treatments, with an action threshold of 0.5 adult female lice per fish (0.2 during the spring wild-smolt window). Counting is mandatory every week, all year.
The friction is that this data is born in three incompatible places. Divers or counting frames produce cage-level tallies; sensor vendors log optical counts; and treatment records sit in a separate operational system.
According to the Stingray Fish Health Report 2025, Norwegian sites are required to report lice counts, sea temperature and treatments to the authorities once a week, producing weekly-granularity time series across the industry.
This same weekly obligation reappears under different regulators abroad — SEPA’s sea-lice framework in Scotland, MAST in Iceland, and DFO’s public reporting in Canada. The stack that automates one adapts to the others.
BarentsWatch publishes much of this Norwegian data openly, but its API has known reliability gaps. The Streckfuss decision-support study, 2024 documents that API calls for detailed farm data “failed with unknown cause” and that threshold data was not obtainable through the API at all. Your flow must therefore treat the API as a source to reconcile against, not a single point of truth.
How do I capture the counts automatically before they reach the report?
Capture the count at the moment it is created and normalize it into Dataverse, so the weekly report becomes a query rather than a manual re-entry. This is where 80% of manual data-entry errors disappear — a figure from Muze’s own production automations.
Three capture paths cover almost every operation:
- Clean API (sensor vendor or BarentsWatch): a scheduled Power Automate HTTP action pulls JSON on a fixed cadence.
- Structured export (CSV/Excel from a counting app): a flow triggers on the file landing in SharePoint.
- Unstructured (diver PDF logs, treatment photos, scanned sheets): AI Builder extracts the numbers.
For the unstructured path, AI Builder’s document processing and prebuilt models read fields from forms and images without custom code. Microsoft’s overview of AI Builder describes prebuilt models ready for common extraction scenarios plus custom models you train on your own document layouts — such as a specific diver’s log sheet.
The facts here are Microsoft’s product capabilities. In Muze’s experience, the AI Builder path is the one that decides whether a project sticks: the API integrations are straightforward, but a single farm can generate a dozen paper-and-photo formats that no connector reads. The teams that automate capture at the source stop firefighting spreadsheets on report day.
The same capture-then-validate pattern underpins other compliance flows, such as automating DFO’s 24-hour mortality event reporting, where the clock starts the moment the event is recorded.
The end-to-end flow: capture → validate → report
The architecture is a linear pipeline with one reconciliation loop against the public dataset:
Farm counts (diver / sensor / CSV)
│
▼
AI Builder ──► extract fields (adult female lice, temp, cage ID, date)
│
▼
Power Automate ──► normalize + write to Dataverse
│
▼
Dataverse ──► validate vs 0.5 threshold + reconcile vs BarentsWatch API
│ │
▼ ▼
Pass → assemble report Mismatch → Teams alert to compliance
│
▼
Mattilsynet weekly submission + audit log| Component | Role | Technology |
|---|---|---|
| Capture trigger | Detects new counts (API poll, file, or image) | Power Automate |
| Field extraction | Reads lice counts from PDFs, photos, forms | AI Builder |
| Normalization + orchestration | Cleans, maps and routes records | Power Automate |
| System of record | Stores counts, thresholds, audit trail | Dataverse |
| Cross-check source | Reconciles internal vs public figures | BarentsWatch API |
| Exception routing | Flags threshold breaches and mismatches | Teams / Power Automate |
| Reporting view | Compliance dashboard for sign-off | Power BI / Power Apps |
This is the same skeleton Muze uses across regulated food and aquaculture work, from Swiss FSVO traceability automation to salmon compliance. The regulator changes; the capture-validate-report backbone does not.
How does validation catch a threshold breach before the regulator does?
Validation runs inside Dataverse the moment a count lands: the flow compares each cage’s adult-female average against the 0.5 lice per fish limit and, if breached, triggers a Teams alert to the compliance lead within the same run — not a week later. Early action is the entire point of the regime.
For context, DFO’s public reporting shows how tight these bands are. Per Fisheries and Oceans Canada’s B.C. sea-lice reporting, average abundance ran at 1.0 in January 2026 against a 1.0 management threshold, with mitigation required inside the March–June wild-salmon out-migration window. A single count crossing the line starts a legal clock.
The validation layer also reconciles internal counts against the BarentsWatch figure for the same site and week. A silent divergence — your system says 0.3, the public dataset says 0.6 — is exactly the discrepancy that turns into a regulatory finding.
“The regulator does not fine you for high lice — that is biology. They fine you for a number you cannot defend. Automating the count-to-report path is really about building an audit trail that answers ‘who counted, when, and against which threshold’ before anyone asks.” — Marco Chávez, Founder of Muze AI Consulting.
Muze reached this validation-first design automating regulatory reporting to SERNAPESCA for one of the world’s five largest salmon farming companies. Chile is the world’s #2 producer, and the same global groups farm both hemispheres — so the pain under a Mattilsynet logo is the pain Muze has already solved under another.
What does a realistic build timeline and result look like?
A pilot covering one region’s sites reaches production in 6–8 weeks: roughly two weeks mapping data sources, two on AI Builder extraction and Dataverse schema, two on the reporting flow, and two on validation with the compliance team. The measurable outcomes track Muze’s proven results.
| Phase | Weeks | Focus | Milestone |
|---|---|---|---|
| 1. Discovery | 1–2 | Map every count source per site | Source inventory |
| 2. Capture | 3–4 | AI Builder models + Dataverse tables | Counts auto-ingested |
| 3. Reporting | 5–6 | Weekly assembly flow | Draft report generated |
| 4. Validation | 7–8 | Threshold + BarentsWatch reconciliation | Compliance sign-off |
Documented results from Muze’s regulatory automation work: 60% reduction in compliance-report preparation time, 80% fewer manual data-entry errors, 3,000+ annual hours saved on manual tasks, and 15–40% savings in direct operating costs. These are Muze’s figures, not external benchmarks.
The data shows weekly reporting is a fixed, non-negotiable cadence. In Muze’s judgment, that predictability is precisely why it automates so well: a stable schema, a stable threshold, and a stable deadline are the ideal conditions for a Power Automate pipeline to run untouched. For the wider regulatory picture across Mattilsynet, SEPA and DFO obligations, the same architecture scales from one regulator to a multi-country portfolio.