Rhindon Cyber logo
    Support & Documentation
    Contact Support

    Operation & Monitoring

    ISO 42001 Annex A.6.2.6 — define monitoring plans for each AI system, log runtime metrics manually or in bulk, and track operational incidents.

    What it is

    Operation & Monitoring at /governance/monitoring stores versioned monitoring plans per AI system, the metrics those plans cover (performance, drift, fairness, safety, availability, cost, etc.), and the runtime records that feed them. Records can be entered manually, uploaded in bulk via CSV, or pushed programmatically from your inference pipeline using a hashed ingest key.

    Each record is automatically classified as ok, warning, or breach based on the metric's thresholds. Breaches can be promoted to a Risk Register entry or a 10.2 Nonconformity from the Incidents tab.

    Who can use it

    • All org members: view plans, metrics, records, and incidents.
    • WorkflowAdmin and OrgAdmin: create plans, define metrics, log records, open incidents.
    • OrgAdmin: approve / supersede plans, manage ingest keys, delete records and incidents.
    • Super Admins: full read/write access via impersonation.

    Tabs

    Plans: Versioned (Draft → Approved → Superseded). Approving a new plan auto-supersedes prior approved plans for the same system.
    Metrics: Per-plan KPI definitions with direction (higher / lower / within range), thresholds, frequency, and owner.
    Records: Manual entry with live breach preview, plus CSV bulk upload (max 1000 rows). CSV headers: metric_key, value, observed_at, notes.
    Incidents: Severity-tracked (low → critical), status workflow (open → investigating → mitigated → closed). Each incident has two promotion actions:
    • Promote to Risk: bumps the linked AI system's risk tier so it surfaces on the Risk Register heatmap, and stamps promoted_risk_id on the incident.
    • Promote to Nonconformity: creates a new entry in the AIMS 10.2 Nonconformity Register with source_type='incident', defaulted to ISO clause A.6.2.6, and stamps promoted_nonconformity_id on the incident.
    Ingest Keys (Enterprise): OrgAdmin / WorkflowAdmin can mint hashed rai_… tokens (optionally bound to a single AI system), copy the plaintext once at issuance, and revoke any active key with a written reason. Revoked keys are rejected by the ingest endpoint immediately and cannot be reactivated.

    CSV bulk upload

    Use the Records tab → Bulk upload. Download the template, fill in one row per observation, and select the target plan. Every metric_keymust already exist on that plan; rows with unknown keys are reported per row.

    Dates accept YYYY-MM-DD or full ISO timestamps. Up to 1000 rows per upload.

    Programmatic ingestion (Enterprise)

    Enterprise tenants can push records via the /api/public/monitoring-metricedge function using a per-system hashed token (rai_…). Tokens are generated by an OrgAdmin and stored hashed; the cleartext is shown exactly once at creation time. Revoking a token disables it immediately.

    Reporting

    The Reports module surfaces a dedicated Monitoring tabwith plan coverage, 30-day breach/warning totals, a heatmap-style trend strip, and a per-metric roll-up table. Both per-plan summaries and the aggregate report export to branded DOCX (RhindonCyber_OperationMonitoring_Report_*.docx).

    Audit trail

    Every plan/metric/record/incident write is mirrored into the platform activity log via fn_audit_monitoring_event. UI-driven actions (DOCX export, CSV bulk upload, ingest-key revoke) write additional rows using the MONITORING_* audit-code family.