Changes, severity, and classification

Change events are what you see in Changes lists in the app (and in notifications). This page explains kinds, severities, the breaking flag, and cause grouping—the machinery that keeps alerts readable when one schema edit touches dozens of routes.

Change event fields (conceptual)

Field	Meaning
kind	Machine-readable classifier (endpoint_removed, response_schema_changed, …).
severity	safe, risky, or breaking (ordinal increases with impact).
breaking	Boolean contract-breaking interpretation—used for filters and urgency.
operation_path	Affected operation (method + path) when applicable.
summary	Short human-readable description safe for chat surfaces.
detail	Structured JSON with specifics (diff hunks, schema names, etc.).
cause_key	Stable grouping token for fan-out from a single root edit.
cause_scope	One of schema, parameter, global, endpoint (internal grouping).
cause_identifier	Human-meaningful identifier (schema name, parameter, path).
affected_domain	Optional domain tag when domain mappings exist.
detected_at	Wall time Intello persisted the event.
acknowledged_at / acknowledged_by	Triage state.

Optional HTTP reference: Core resources.

Representative change kinds

Exact enums evolve, but you should expect kinds aligned to OpenAPI semantics:

• Lifecycle — endpoint_added, endpoint_removed, endpoint_deprecated
• Parameters — parameter_added, parameter_removed, parameter_type_changed
• Schemas — request_schema_changed, response_schema_changed, required_field_added, required_field_removed, enum_changed
• Security — auth_changed, security_changed

Use kind for automation (e.g., open Jira subtasks by template). Use severity + breaking for paging policy.

Severity vs breaking

• severity is a graded signal (safe < risky < breaking).
• breaking answers “would this typically force a client change?”—independent but usually correlated with severity=breaking.

Alert preferences can combine minimum severity with notify_on_breaking to implement policies like “page only on breaking boolean, but show risky in email digests.”

Cause keys and grouped views

Vendor refactors often change one shared schema referenced by many operations. Without grouping, you would see N near-duplicate rows.

cause_key ties those rows to a single root cause. List endpoints may return collapsed group rows with counts and aggregated operation lists; acknowledgements can target:

• a single change id, or
• a group via Acknowledge group in the UI (or the HTTP equivalent documented for your deployment).

Acknowledgements

Acknowledging marks triage completeness—it does not revert vendor changes. Patterns:

• Per-event ack for surgical noise reduction.
• Group ack when a single schema rollout explains dozens of lines.

Developers sending JSON directly may use a body like:

{
  "acknowledged_by": "oncall@company.com"
}

Affected domains

When you map product domains (e.g., billing, auth) to operations, Intello can stamp affected_domain on events—useful for routing alerts to owning teams.

Details: Domain mappings.

Related topics

• How diffs are generated
• Risk and alert relevance
• Reducing alert fatigue