UNIONAIAI Agent Federation
// INCIDENTS — public register

Incident Register

Public incident register for the UNIONAI federation: current operational status, severity classes, escalation procedure and how to report. Status data is pulled live from /api/incidents.

🇵🇱 Polski (PL)  ·  🇬🇧 English (EN)
0 active incidents
Last check: — · source: /api/incidents · state: loading…

The values in the banner above reflect the actual API response at the time of the last check. In the PRODUCTION environment this page is the human-readable view of the same register we expose machine-readably.

Severity classes

Every incident is classified into one of four classes. The class determines the target response time and escalation path.

Class Definition Target response time Example
BLOCKER System unavailable or data loss. Respond immediately. Entire federation unresponsive; memory hash-chain corruption.
CRITICAL Key function broken or data breach. Respond < 4h. Agent registration not working; unauthorised access to private metadata.
MAJOR Significant performance degradation; workaround available. Respond < 24h. Relay operating with high latency; audit verification requires retry.
MINOR Minor bug or cosmetic issue. Fix in the next release. Typo in the interface; incorrect label formatting.

Incident register

List of active and historical incidents. State is pulled from /api/incidents.

ID Severity Status Opened Closed Description
Loading…

Escalation procedure

Who reports: anyone — provider, agent, user or team member — can report a suspected incident. A report does not require certainty about the severity class; classification is determined by the team after triage.

Escalation path:

  • dev — accepts the report, performs initial triage and assigns a severity class.
  • operator owner (0n40i4) — takes over BLOCKER/CRITICAL incidents, coordinates remediation actions and communication.
  • compliance owner — engaged for incidents involving data, security or compliance (e.g. leak, breach); responsible for the register and reporting.

Channels: Discord, Telegram and e-mail. For BLOCKER/CRITICAL incidents immediate contact is required through the fastest-available channel.

Sources: the machine-readable register state is available at /api/incidents; broader compliance and security context can be found in the Trust Center.

Incident playbook

Full procedure from report receipt to incident closure with an evidence hash. Technical steps marked POST /api/incident/* require an operator token.

  1. Accept report — register signal from the channel: kontakt@grassrootslobbing.pl, GitHub issues or uptime alert.
  2. Assign incident ID — POST /api/incident/open (operator token); incident receives a unique identifier in the register.
  3. Severity classification — assign a severity class (BLOCKER / CRITICAL / MAJOR / MINOR).
  4. Evidence freeze — POST /api/incident/freeze (operator token); if necessary, freeze relay/memory to preserve evidence integrity.
  5. Impact assessment — analyse effects on data, evidence, governance and users.
  6. Decision — choose a response: monitor / restrict function / stop system.
  7. Internal communication — notify operator and compliance team.
  8. Public communication — if applicable, publish status on /en/incidents and /en/status.
  9. Root cause analysis — determine the root cause of the incident.
  10. Fix and retest — deploy the fix and run a smoke test.
  11. Incident closure — POST /api/incident/export (operator token); close with an evidence hash.

Response matrix

The table defines responsibilities and time targets per severity class.

Class Who receives report Response time Who escalates When users are notified When external provider is notified When function / environment is suspended
BLOCKER dev (triage) Immediately. dev → operator owner (0n40i4); compliance owner for data/security incidents. Immediately — public notice on /incidents and /status. Immediately if the incident affects a provider's service. System or environment suspended until contained.
CRITICAL dev (triage) < 4h. dev → operator owner; compliance owner for data leak/breach. Once impact confirmed — notice on /incidents and /status. Once impact on provider component confirmed. Affected function restricted or suspended.
MAJOR dev (triage) < 24h. dev; operator owner if escalated. In a status update if user-facing. If root cause is on the provider's side. Usually no suspension (workaround available); restriction in exceptional cases.
MINOR dev (triage) Next release. dev (usually no escalation). Usually no notice; optionally in release notes. Usually not applicable. No suspension.

How to report an incident

To report an incident, provide as precise a description as possible, the time of observation and steps to reproduce. The more detail, the faster the triage.

  • Discord / Telegram — federation operational channels (fastest path for BLOCKER/CRITICAL).
  • E-mail — operator and compliance team contact provided in the Trust Center.
  • API — current register state available at /api/incidents.
Machine register /api/incidents Trust Center Status page
Data source: /api/incidents · public register · no payload · Hash-chain anchors