Pipeline Health Reports

The Reports page surfaces what the Memory Database has recorded across a time range: build volume, distribution channel split, top software, compliance pre-check verdicts, and audit-chain integrity. The same data exports as CSV (denormalised, Excel-friendly) and as an 8-page A4 PDF (branded, suitable for compliance archives or stakeholder reports).

This chapter covers what the report shows, how the data is sourced, the per-operator opt-in, and the DACH co-determination position.

Where the data comes from #

Every figure in the report traces back to a row in the Memory Database. No external services, no telemetry endpoint, no separate report database.

The report covers the activity of the local MAS install — the SQLite (WAL) Memory Database is single-machine by design.

The two deferred sections (Backend reachability, Stage performance) appear as honest placeholder cards reading "Collecting metrics — appears in a later release" rather than showing fabricated or empty data.

The Reports page #

Navigation: side-rail → Insight → Reports.

The header carries a range selector (24 h / 7 d / 30 d) and the CSV / PDF Report export buttons. The body is four rows of cards:

1. KPI tiles — Builds, Success rate, Distributions, Average builds per active day. Each tile shows the current value and the trend versus the equivalent prior period.
2. Pipeline activity (line chart, daily) + Top software (volume bars, deduped by UpgradeCode).
3. Distribution channel split (donut: SCCM / Intune / Failed) + Pre-Check verdicts (Passed / Warnings / Blocked with top findings).
4. Backend reachability + Time per stage — both placeholders in the current release.

Below the cards, the per-operator section appears if the corresponding opt-in is on (see next section). When off, an aggregated-only banner explains the position with the works-council reference.

The footer shows the data source dialect, the snapshot timestamp, the operator who opened the page, and the audit-log integrity verdict.

Per-operator reporting #

By default, the Reports page is aggregated only. Builds and distributions are counted in total — no individual operator's name appears anywhere on the page or in the exports. The aggregated view shows whether the team is shipping, where the failures cluster, and how the distribution channels are loaded. None of that requires attributing the work to a specific person.

Per-operator reporting is an opt-in feature guarded by an explicit Settings toggle:

• Settings → Reports → Per-operator reporting — default off. Flipping it on opens a confirmation dialog that re-states the legal position and demands a checkbox tick before the change applies.

When the toggle is on, the Reports page adds a per-operator breakdown card listing each DOMAIN\user with their build count, distribution count, and last activity timestamp. CSV and PDF exports include the same breakdown.

Every flip of the toggle (off → on, on → off) is recorded in the tamper-evident audit log as a ReportPerActorToggled entry. The payload carries the before-state, the after-state, the operator who flipped it, and a UTC timestamp. The on/off history is reconstructable from the audit log indefinitely.

DACH co-determination — § 87 BetrVG #

Per-operator attribution can qualify as introducing a technical system that monitors employee behaviour or performance. In German jurisdictions that is subject to works-council co-determination (Mitbestimmungspflicht) under § 87 Abs. 1 Nr. 6 of the Betriebsverfassungsgesetz.

MAS's position is two-fold:

• Default off — out of the box, MAS does not enable per-operator reporting. An installation can run the Reports page indefinitely without surfacing any individual's activity.
• Auditable opt-in — when the toggle is flipped on, the change is recorded in the tamper-evident audit log with the actor and timestamp. A compliance review can reconstruct "when did this installation start tracking per-operator activity, and who authorised it".

The in-app confirmation dialog and the inline notice card on Settings → Reports surface this explicitly. The PDF export's optional methodology page also includes the notice when the disclaimer toggle is on (default).

Confirming with the works council and the data-protection officer before enabling is the customer's responsibility. MAS provides the default, the opt-in mechanism, and the audit trail; the policy decision remains with the customer.

What an external auditor can verify #

Given access to the Memory Database, an external auditor can confirm the per-operator reporting position via two queries:

-- Current state of the toggle
SELECT TOP 1 PayloadJson, ActedAt, Actor
  FROM AuditEntry
 WHERE EventType = 'ReportPerActorToggled'
 ORDER BY ActedAt DESC;
-- => payload.newValue tells you on/off as of that timestamp

-- Full toggle history
SELECT ActedAt, Actor, PayloadJson
  FROM AuditEntry
 WHERE EventType = 'ReportPerActorToggled'
 ORDER BY ActedAt;

If no ReportPerActorToggled entries exist, the toggle has never been flipped and the installation has been aggregated-only since it was first installed.

CSV export #

Single-file, RFC 4180-conformant, UTF-8 with BOM (so Excel auto-detects). The file uses section-header rows to separate the logical blocks:

# REPORT HEADER
"Field","Value"
"RangeStartUtc","2026-06-01T00:00:00+00:00"
...

# KPI SUMMARY
"Metric","Current","Previous period"
"Builds","142","124"
...

# DAILY ACTIVITY
"Date","Builds","Distributions","DistributionFailures"
"2026-06-01","18","12","0"
...

The per-operator section appears only when the opt-in is on. This mirrors the in-app rule so an operator cannot sidestep the gate by exporting CSV instead of looking at the page.

The export action is recorded in the audit log as ReportExported with the file path, the range, the format, and the anonymisation mode.

PDF export #

The PDF is an 8-page A4 portrait document with a navy-cover hero, a table of contents, an executive summary, and dedicated pages for build activity, distribution channels, top software, pre-check verdicts, and (optionally) the methodology page.

The methodology page is conditional on the Include disclaimer toggle in Settings → Reports. With the disclaimer on (default), page 8 contains:

• Methodology block — data source, anonymisation mode, time zone, snapshot timestamp, operator.
• Audit-log integrity strip — verdict from the most recent chain verification with the row count and timestamp.
• DACH co-determination notice — the § 87 BetrVG wording with the installation's current per-operator-reporting state inline.

With the disclaimer off, page 8 is suppressed entirely. The header / footer metadata on every other page remains, so the document still identifies its source and time range.

The export action is audit-logged as ReportExported.

Related #

• ../600-Memory-DB/650-Audit-Chain — how the integrity strip is computed
• 820-GDPR-Export — Subject Access Request bundle for a single actor
• Settings → Reports — in-app opt-in