Insights and personal work

Manual home · Role guides · Coverage · Gaps

Manual conventions and recovery apply to every workflow. Evidence level: code inspected; related tests were inspected, not executed.

flowchart LR
  A[Filter operational evidence] --> B[Inspect underlying records]
  B --> C[Allocate follow-up]
  C --> D[Acknowledge alert]
  D --> E[Investigate and act]
  E --> F[Resolve alert]
  B --> G[Export selected scope]
  C --> H[Recipient notification and activity trail]

INS-01 — Use the Command Centre and follow work signals

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: use the Command Centre and follow work signals.

Actors and access: qms:read; teams:read additionally required for company/team scope filters.

Prerequisites: Tenant operational records and a meaningful selected period.

Entry point: Command Centre /.

1. Select the supported time period/date range and organisation filters.
2. Inspect summary/workload/quality signals and their data availability.
3. Follow cards into reviews, interactions, alerts or coaching and verify the underlying records.

Result: A filtered operational view directs users to actionable records.

Exceptions and recovery: Do not infer production readiness from seeded/demo data. The current server builds the summary from repositories, while deployment data may be demonstrative; review data provenance and period before reporting results.

Source evidence: services/api/src/app.ts; services/api/src/command-centre.ts; apps/web/src/features/command-centre/command-centre.tsx.

INS-02 — Filter reports, inspect audit/knowledge results and export CSV

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: filter reports, inspect audit/knowledge results and export CSV.

Actors and access: qms:read at report APIs; local /reports and insights navigation can require alerts:read.

Prerequisites: Available submitted audits and related interaction/scoring records.

Entry point: Reports & Insights; Audit reports; Knowledge adherence; Reports library.

1. Choose report and supported date, organisation, reviewer, scorecard and other filters.
2. Inspect rows/aggregates and continue pagination; open linked evidence when investigating a result.
3. Export CSV from the same selected filter context and check report provenance.

Result: A bounded report/export represents the selected dataset.

Exceptions and recovery: Knowledge adherence requires its backing knowledge/Atom/Molecule services. Empty/partial source data is not zero real-world activity. Pilot analytics is a supporting API, not an automatically complete rollout sign-off.

Source evidence: services/api/src/reports/routes.ts; apps/web/src/features/reports/reports.tsx; packages/contracts/src/reports.ts.

INS-03 — Save and manage personal filters and report views

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: save and manage personal filters and report views.

Actors and access: qms:read; saved records are tenant-and-owner scoped.

Prerequisites: A useful supported filter/report configuration.

Entry point: Interactions/report saved-view controls; saved-views API.

1. Set filters and save a named personal filter or report view.
2. List/reopen it and inspect any stored report-view configuration.
3. Update a report view or delete an obsolete filter/view using the supported action.

Result: Reusable personal views persist without granting other users access.

Exceptions and recovery: A deleted/unavailable source can change future results. Saved views are not scheduled report delivery and are not automatically shared tenant-wide.

Source evidence: services/api/src/saved-views/routes.ts; packages/contracts/src/saved-views.ts; apps/web/src/features/reports/reports.tsx.

INS-04 — Investigate performance and compliance risk

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: investigate performance and compliance risk.

Actors and access: alerts:read for performance API and local intelligence access; related report APIs use qms:read.

Prerequisites: Submitted review results, critical-failure signals and appropriate filters.

Entry point: Intelligence → Performance; Compliance & Risk.

1. Inspect performance/risk summaries and severity distributions.
2. Drill into high-risk interactions/reviews and verify evidence and scorecard context.
3. Allocate follow-up through alerts, corrections, coaching or independent review.

Result: A manager can trace a risk signal to reviewed evidence and an accountable action.

Exceptions and recovery: A risk indicator is not an adjudicated finding. Data may be sparse or demonstrative; confirm source records and avoid changing an immutable audit just to remove a signal.

Source evidence: services/api/src/alerts/routes.ts; apps/web/src/features/compliance/compliance-risk.tsx; apps/web/src/features/intelligence/intelligence.tsx.

INS-05 — Triage, assign, acknowledge and resolve alerts

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: triage, assign, acknowledge and resolve alerts.

Actors and access: alerts:read to inspect; alerts:manage to update.

Prerequisites: An existing generated alert.

Entry point: Intelligence → Alerts.

1. Filter/open alerts and inspect source evidence, severity and current owner.
2. Assign and/or acknowledge supported alerts, then perform the necessary investigation.
3. Resolve the alert when the recorded follow-up is complete and inspect activity.

Result: Alert status and assignment are recorded with mutation events.

Exceptions and recovery: Resolved alerts cannot be reopened through the update API. Alert generation uses deduplication; repeated reads are not a guarantee of new alert records. Acknowledge is not resolution.

Source evidence: services/api/src/alerts/routes.ts; services/api/src/alerts/dedupe.ts; apps/web/src/features/intelligence/intelligence.tsx.

INS-06 — Create and maintain alert rules

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: create and maintain alert rules.

Actors and access: alerts:read to browse; alerts:manage to create/update.

Prerequisites: Supported rule criteria and any valid Molecule reference.

Entry point: Intelligence → Alert rules.

1. Create a rule with its conditions/severity/routing fields.
2. Inspect and update the rule and its enabled configuration.
3. Review generated alert evidence after eligible evaluation; adjust future rule behaviour deliberately.

Result: Validated rules participate in alert evaluation.

Exceptions and recovery: Rule configuration does not retroactively rewrite historical reviews. Missing dependencies/provider failures can prevent evaluation; use job status/evidence instead of assuming every rule has executed.

Source evidence: services/api/src/alert-rules/routes.ts; services/api/src/alert-rules/evaluation-handler.ts; apps/web/src/features/alert-rules/alert-rules.tsx.

INS-07 — Read notifications and inspect personal work

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: read notifications and inspect personal work.

Actors and access: Authenticated principal; recipient/user-scoped notification and work queries.

Prerequisites: Assigned/created work or notifications for the current user.

Entry point: Notifications inbox; My work summary.

1. Open the inbox/work summary and inspect unread counts and linked tasks.
2. Follow an item to its authorised destination.
3. Mark one notification read or mark all read; streamed updates refresh the inbox when available.

Result: Read state is updated for the recipient and tasks remain independently permission checked.

Exceptions and recovery: A notification link does not grant access to its target. Stale/expired work can disappear or become inaccessible; refresh and use the domain queue rather than assuming the notification is current.

Source evidence: services/api/src/notifications/routes.ts; services/api/src/work/my-work-routes.ts; apps/web/src/features/notifications/notifications.tsx.

INS-08 — Inspect the tenant mutation trail

Status: Implemented. Verification: code inspected; no runtime completion claim.

Purpose: inspect the tenant mutation trail.

Actors and access: audit-trail:read.

Prerequisites: Recorded tenant mutation events.

Entry point: Activity.

1. Filter by event type or aggregate and page through the activity timeline.
2. Inspect actor, request correlation and linked entity metadata.
3. Use the underlying record/workflow to investigate; retain the event as historical evidence.

Result: An append-only event history supports traceability.

Exceptions and recovery: The trail deliberately excludes transcripts, draft answers/comments and media content. It has no update/delete workflow. Platform control-plane events live in OPS-07 rather than the tenant trail.

Source evidence: services/api/src/mutation-events/routes.ts; services/api/src/mutation-events/trail.ts; apps/web/src/features/activity/activity.tsx.